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 ~]$

> 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

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.

OH, i see.
Thanks a lot.

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/

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

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/

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/

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/

<snip>

not so bloody revolutionary now, is it?

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