www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - DMD0.110's accessibility BUG?

reply uframer <uframer sina100.com> writes:
Hi guys, should this be right?
<code>
// test D :)
import std.stdio;

class C
{
// they are p-r-i-v-a-t-e
private:
 int a=1;
 int b=2;
}

void main()
{
 C c = new C();
 // but see what happened
 int i=c.b;
 writefln("%d", i);
 // this compiles!
}
</code>
The RESULT is(on an linux):
[uframer uFramerMagicLinux ~]$ dmd
Digital Mars D Compiler v0.110
Copyright (c) 1999-2004 by Digital Mars written by Walter Bright
...
[uframer uFramerMagicLinux ~]$ dmd test.d
gcc test.o -o test -lphobos -lpthread -lm
[uframer uFramerMagicLinux ~]$ ./test
2
[uframer uFramerMagicLinux ~]$
Jan 09 2005
next sibling parent reply Vathix <vathix dprogramming.com> writes:
 Hi guys, should this be right?

The code is correct; it's not a bug. It's D`s solution to friendship. Check out these answers, http://www.prowiki.org/wiki4d/wiki.cgi?ShortFrequentAnswers
Jan 09 2005
parent uframer <uframer sina100.com> writes:
OH, i see.
Thanks a lot.
Jan 10 2005
prev sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
On Sun, 09 Jan 2005 20:53:55 -0500, uframer wrote:

 Hi guys, should this be right?

Read the manual. You'll find that this is an intended access capability for all members of the same module.
Jan 09 2005
parent reply "Simon Buchan" <buchan.home ihug.co.nz> writes:
On Sun, 09 Jan 2005 06:59:05 -0800, John Reimer <brk_6502 yahoo.com> wrote:

 On Sun, 09 Jan 2005 20:53:55 -0500, uframer wrote:

 Hi guys, should this be right?

Read the manual. You'll find that this is an intended access capability for all members of the same module.

I can understand (but disagree) with the DEFAULT being package/module (whatever D uses) but explicitly setting private should mean nobody should see it. Walter has his own veiws, though. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Jan 14 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
On Fri, 14 Jan 2005 21:12:30 +1300, Simon Buchan wrote:

 On Sun, 09 Jan 2005 06:59:05 -0800, John Reimer <brk_6502 yahoo.com> wrote:
 
 On Sun, 09 Jan 2005 20:53:55 -0500, uframer wrote:

 Hi guys, should this be right?

Read the manual. You'll find that this is an intended access capability for all members of the same module.

I can understand (but disagree) with the DEFAULT being package/module (whatever D uses) but explicitly setting private should mean nobody should see it. Walter has his own veiws, though.

I'm no OOP guru, although I pick up the ideas and buzz-words bit by bit over the years (comprehending about 25% of this input, then promptly forgetting about 99% of that 25% :-( ), so perhaps it's not safe for me to comment on the rightness or wrongness of the issue. But because I'm sometimes bold and stupid :-) ... I don't see module level access to private variables being a terrible problem. The majority of the time, classes (and procedures) that share the same module name are together in there for very specific reason, otherwise each class is separated into individual modules. Nothing outside the module should have access to these private members, but it could be useful for the same module members to have access to them. Perhaps this is more the case with private methods over private variables. On the other hand, perhaps we /should/ ask why we even would need to access those private members from another class or procedure in the first place (even in the very specific context of the module). Is this an indication of bad OOP design? Is the ability to do so the fault of the compiler or the programmer? What is the significance of this access as compared to the "friend" attribute of C++? Now, I can't remember if packages share the same trait (modules in the same directory); if these modules had classes that could access other module class' private variables or methods, then I would start wondering about the purpose of the private attribute. For now, I guess you just use the "feature" or don't use it if you don't like it. I do agree that D has some... uh... "different" OOP approaches when compared to other languages. But that may be a result of D being one of those hybrid languages. It's OOP if you want it to be, but its base is imperative. This is much the way Modula-3 was designed, but I think D does a better job. OT: I started studying Modula-3 again. It used to be one of those languages that I /thought/ I worshiped. That was until I started getting into it more. Just looking at features offered by a language really doesn't tell you how great it is. After reviewing it's syntax more in sample programs, I just about croaked. At first I thought, "Hey, it's just new... be patient, it'll grow on you." But later I gave up on that theory. I'm afraid I'm stuck with C-type syntax. I can't fathom how one can get used to the almost pedantic style of programming in pascal-like languages. I guess people are attracted to what they are used to. Later John
Jan 14 2005
next sibling parent "Simon Buchan" <buchan.home ihug.co.nz> writes:
On Fri, 14 Jan 2005 01:24:39 -0800, John Reimer <brk_6502 yahoo.com> wrote:

 On Fri, 14 Jan 2005 21:12:30 +1300, Simon Buchan wrote:

 On Sun, 09 Jan 2005 06:59:05 -0800, John Reimer <brk_6502 yahoo.com>  
 wrote:

 On Sun, 09 Jan 2005 20:53:55 -0500, uframer wrote:

 Hi guys, should this be right?

Read the manual. You'll find that this is an intended access capability for all members of the same module.

I can understand (but disagree) with the DEFAULT being package/module (whatever D uses) but explicitly setting private should mean nobody should see it. Walter has his own veiws, though.

I'm no OOP guru, although I pick up the ideas and buzz-words bit by bit over the years (comprehending about 25% of this input, then promptly forgetting about 99% of that 25% :-( ), so perhaps it's not safe for me to comment on the rightness or wrongness of the issue. But because I'm sometimes bold and stupid :-) ... I don't see module level access to private variables being a terrible problem. The majority of the time, classes (and procedures) that share the same module name are together in there for very specific reason, otherwise each class is separated into individual modules. Nothing outside the module should have access to these private members, but it could be useful for the same module members to have access to them. Perhaps this is more the case with private methods over private variables.

I can see what you're saying here, though I like to think that the way the code is STORED should have absolutly no effect on the program: imagine a quick'n'dirty program that became not so quick, (but hopefully less dirty too) split into multiple files, then a whole bunch of errors and crud, meaning (correctly or not) our unlucky coder gets to redesign his whole program. Which is also why I think multiple modules should be able to be defined in one file (each making a seperate object) Note however that D does have the package attribute, which as far as I know should do what private does now, but MAKES SENSE. (It may only be for imports or something atm... but shouldn't be IMHO)
 On the other hand, perhaps we /should/ ask why we even would need to
 access those private members from another class or procedure in the first
 place (even in the very specific context of the module). Is this an
 indication of bad OOP design? Is the ability to do so the fault of the
 compiler or the programmer?  What is the significance of this access as
 compared to the "friend" attribute of C++?

I should think that generally the whole 'friend' thing is a workaround for unimplented C++ features (nested classes or something) and should be abolished.
 Now, I can't remember if packages share the same trait (modules in the
 same directory);  if these modules had classes that could access other
 module class' private variables or methods, then I would start wondering
 about the purpose of the private attribute.

I don't think D cares where files are (or even if there are files that will be linked to this one, thats the job of the linker)
 For now, I guess you just use the "feature" or don't use it if you don't
 like it.  I do agree that D has some... uh... "different" OOP approaches
 when compared to other languages. But that may be a result of D being one
 of those hybrid languages.  It's OOP if you want it to be, but its base
 is imperative.  This is much the way Modula-3 was designed, but I think D
 does a better job.

<lame_excuse>Ehh, but I don't like reading that kind of code... </lame_excuse>
 OT:  I started studying Modula-3 again.  It used to be one of those
 languages that I /thought/ I worshiped.  That was until I started getting
 into it more.  Just looking at features offered by a language really
 doesn't tell you how great it is.  After reviewing it's syntax more in
 sample programs, I just about croaked.  At first I thought, "Hey, it's
 just new... be patient, it'll grow on you."  But later I gave up on that
 theory.  I'm afraid I'm stuck with C-type syntax. I can't fathom how one
 can get used to the almost pedantic style of programming in
 pascal-like languages. I guess people are attracted to what they are used
 to.

Pedantic code syntax is _theoreticly_ good, which _theoreticly_ is as good as good in _practice_. I will never be able to give up the _ability_ to write programs in ONE EXPRESSION! even if I would never actually use it... (which is why we have the Obfusicated C Code Contest :D) About the only thing I really miss in C style syntax (apart from NOT HAVING C++'s template syntax) is more flexibity with functions, ie type-enforced variable args (something like func(float, *[int, string]) ? Obviously a syntax nightmare) and multiple/overloadable return types.
 Later

 John

-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Jan 14 2005
prev sibling next sibling parent "Simon Buchan" <buchan.home ihug.co.nz> writes:
On Fri, 14 Jan 2005 01:24:39 -0800, John Reimer <brk_6502 yahoo.com> wrote:

 On Fri, 14 Jan 2005 21:12:30 +1300, Simon Buchan wrote:

 On Sun, 09 Jan 2005 06:59:05 -0800, John Reimer <brk_6502 yahoo.com>  
 wrote:

 On Sun, 09 Jan 2005 20:53:55 -0500, uframer wrote:

 Hi guys, should this be right?

Read the manual. You'll find that this is an intended access capability for all members of the same module.

I can understand (but disagree) with the DEFAULT being package/module (whatever D uses) but explicitly setting private should mean nobody should see it. Walter has his own veiws, though.

I'm no OOP guru, although I pick up the ideas and buzz-words bit by bit over the years (comprehending about 25% of this input, then promptly forgetting about 99% of that 25% :-( ), so perhaps it's not safe for me to comment on the rightness or wrongness of the issue. But because I'm sometimes bold and stupid :-) ... I don't see module level access to private variables being a terrible problem. The majority of the time, classes (and procedures) that share the same module name are together in there for very specific reason, otherwise each class is separated into individual modules. Nothing outside the module should have access to these private members, but it could be useful for the same module members to have access to them. Perhaps this is more the case with private methods over private variables.

I can see what you're saying here, though I like to think that the way the code is STORED should have absolutly no effect on the program: imagine a quick'n'dirty program that became not so quick, (but hopefully less dirty too) split into multiple files, then a whole bunch of errors and crud, meaning (correctly or not) our unlucky coder gets to redesign his whole program. Which is also why I think multiple modules should be able to be defined in one file (each making a seperate object) Note however that D does have the package attribute, which as far as I know should do what private does now, but MAKES SENSE. (It may only be for imports or something atm... but shouldn't be IMHO)
 On the other hand, perhaps we /should/ ask why we even would need to
 access those private members from another class or procedure in the first
 place (even in the very specific context of the module). Is this an
 indication of bad OOP design? Is the ability to do so the fault of the
 compiler or the programmer?  What is the significance of this access as
 compared to the "friend" attribute of C++?

I should think that generally the whole 'friend' thing is a workaround for unimplented C++ features (nested classes or something) and should be abolished.
 Now, I can't remember if packages share the same trait (modules in the
 same directory);  if these modules had classes that could access other
 module class' private variables or methods, then I would start wondering
 about the purpose of the private attribute.

I don't think D cares where files are (or even if there are files that will be linked to this one, thats the job of the linker)
 For now, I guess you just use the "feature" or don't use it if you don't
 like it.  I do agree that D has some... uh... "different" OOP approaches
 when compared to other languages. But that may be a result of D being one
 of those hybrid languages.  It's OOP if you want it to be, but its base
 is imperative.  This is much the way Modula-3 was designed, but I think D
 does a better job.

<lame_excuse>Ehh, but I don't like reading that kind of code... </lame_excuse>
 OT:  I started studying Modula-3 again.  It used to be one of those
 languages that I /thought/ I worshiped.  That was until I started getting
 into it more.  Just looking at features offered by a language really
 doesn't tell you how great it is.  After reviewing it's syntax more in
 sample programs, I just about croaked.  At first I thought, "Hey, it's
 just new... be patient, it'll grow on you."  But later I gave up on that
 theory.  I'm afraid I'm stuck with C-type syntax. I can't fathom how one
 can get used to the almost pedantic style of programming in
 pascal-like languages. I guess people are attracted to what they are used
 to.

Pedantic code syntax is _theoreticly_ good, which _theoreticly_ is as good as good in _practice_. I will never be able to give up the _ability_ to write programs in ONE EXPRESSION! even if I would never actually use it... (which is why we have the Obfusicated C Code Contest :D) About the only thing I really miss in C style syntax (apart from NOT HAVING C++'s template syntax) is more flexibity with functions, ie type-enforced variable args (something like func(float, *[int, string]) ? Obviously a syntax nightmare) and multiple/overloadable return types.
 Later

 John

-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Jan 14 2005
prev sibling parent reply "Simon Buchan" <buchan.home ihug.co.nz> writes:
On Fri, 14 Jan 2005 01:24:39 -0800, John Reimer <brk_6502 yahoo.com> wrote:

 On Fri, 14 Jan 2005 21:12:30 +1300, Simon Buchan wrote:

 On Sun, 09 Jan 2005 06:59:05 -0800, John Reimer <brk_6502 yahoo.com>  
 wrote:

 On Sun, 09 Jan 2005 20:53:55 -0500, uframer wrote:

 Hi guys, should this be right?

Read the manual. You'll find that this is an intended access capability for all members of the same module.

I can understand (but disagree) with the DEFAULT being package/module (whatever D uses) but explicitly setting private should mean nobody should see it. Walter has his own veiws, though.

I'm no OOP guru, although I pick up the ideas and buzz-words bit by bit over the years (comprehending about 25% of this input, then promptly forgetting about 99% of that 25% :-( ), so perhaps it's not safe for me to comment on the rightness or wrongness of the issue. But because I'm sometimes bold and stupid :-) ... I don't see module level access to private variables being a terrible problem. The majority of the time, classes (and procedures) that share the same module name are together in there for very specific reason, otherwise each class is separated into individual modules. Nothing outside the module should have access to these private members, but it could be useful for the same module members to have access to them. Perhaps this is more the case with private methods over private variables.

I can see what you're saying here, though I like to think that the way the code is STORED should have absolutly no effect on the program: imagine a quick'n'dirty program that became not so quick, (but hopefully less dirty too) split into multiple files, then a whole bunch of errors and crud, meaning (correctly or not) our unlucky coder gets to redesign his whole program. Which is also why I think multiple modules should be able to be defined in one file (each making a seperate object) Note however that D does have the package attribute, which as far as I know should do what private does now, but MAKES SENSE. (It may only be for imports or something atm... but shouldn't be IMHO)
 On the other hand, perhaps we /should/ ask why we even would need to
 access those private members from another class or procedure in the first
 place (even in the very specific context of the module). Is this an
 indication of bad OOP design? Is the ability to do so the fault of the
 compiler or the programmer?  What is the significance of this access as
 compared to the "friend" attribute of C++?

I should think that generally the whole 'friend' thing is a workaround for unimplented C++ features (nested classes or something) and should be abolished.
 Now, I can't remember if packages share the same trait (modules in the
 same directory);  if these modules had classes that could access other
 module class' private variables or methods, then I would start wondering
 about the purpose of the private attribute.

I don't think D cares where files are (or even if there are files that will be linked to this one, thats the job of the linker)
 For now, I guess you just use the "feature" or don't use it if you don't
 like it.  I do agree that D has some... uh... "different" OOP approaches
 when compared to other languages. But that may be a result of D being one
 of those hybrid languages.  It's OOP if you want it to be, but its base
 is imperative.  This is much the way Modula-3 was designed, but I think D
 does a better job.

<lame_excuse>Ehh, but I don't like reading that kind of code... </lame_excuse>
 OT:  I started studying Modula-3 again.  It used to be one of those
 languages that I /thought/ I worshiped.  That was until I started getting
 into it more.  Just looking at features offered by a language really
 doesn't tell you how great it is.  After reviewing it's syntax more in
 sample programs, I just about croaked.  At first I thought, "Hey, it's
 just new... be patient, it'll grow on you."  But later I gave up on that
 theory.  I'm afraid I'm stuck with C-type syntax. I can't fathom how one
 can get used to the almost pedantic style of programming in
 pascal-like languages. I guess people are attracted to what they are used
 to.

Pedantic code syntax is _theoreticly_ good, which _theoreticly_ is as good as good in _practice_. I will never be able to give up the _ability_ to write programs in ONE EXPRESSION! even if I would never actually use it... (which is why we have the Obfusicated C Code Contest :D) About the only thing I really miss in C style syntax (apart from NOT HAVING C++'s template syntax) is more flexibity with functions, ie type-enforced variable args (something like func(float, *[int, string]) ? Obviously a syntax nightmare) and multiple/overloadable return types.
 Later

 John

-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Jan 14 2005
parent "Simon Buchan" <buchan.home ihug.co.nz> writes:
<snip>

not so bloody revolutionary now, is it?

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Jan 14 2005