digitalmars.D.bugs - DMD0.110's accessibility BUG?
- uframer (30/30) Jan 09 2005 Hi guys, should this be right?
- Vathix (3/4) Jan 09 2005 The code is correct; it's not a bug. It's D`s solution to friendship.
- uframer (2/2) Jan 10 2005 OH, i see.
- John Reimer (3/4) Jan 09 2005 Read the manual. You'll find that this is an intended access capability
- Simon Buchan (8/12) Jan 14 2005 I can understand (but disagree) with the DEFAULT being package/module
- John Reimer (41/57) Jan 14 2005 I'm no OOP guru, although I pick up the ideas and buzz-words bit by bit
- Simon Buchan (36/99) Jan 14 2005 I can see what you're saying here, though I like to think that the way
- Simon Buchan (36/99) Jan 14 2005 I can see what you're saying here, though I like to think that the way
- Simon Buchan (36/99) Jan 14 2005 I can see what you're saying here, though I like to think that the way
-
Simon Buchan
(4/4)
Jan 14 2005
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
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
uframer <uframer sina100.com> 
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
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: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/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 14 2005
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: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 JohnOn Sun, 09 Jan 2005 20:53:55 -0500, uframer wrote: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.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 14 2005
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: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 Sun, 09 Jan 2005 06:59:05 -0800, John Reimer <brk_6502 yahoo.com> wrote: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 Sun, 09 Jan 2005 20:53:55 -0500, uframer wrote: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.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.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
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: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 Sun, 09 Jan 2005 06:59:05 -0800, John Reimer <brk_6502 yahoo.com> wrote: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 Sun, 09 Jan 2005 20:53:55 -0500, uframer wrote: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.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.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
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: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 Sun, 09 Jan 2005 06:59:05 -0800, John Reimer <brk_6502 yahoo.com> wrote: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 Sun, 09 Jan 2005 20:53:55 -0500, uframer wrote: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.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.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
<snip> not so bloody revolutionary now, is it? -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Jan 14 2005