On 2008-08-21 13:11:15 +0200, DF <deefriend@ymail.com> said:

> Neil Vice Wrote:
> 
>> DF wrote:
>>> Robert Fraser Wrote:
>>> 
>>>> DF wrote:
>>>>> Why can private fields be accessed from other methods or classes in the same module?
>>>>> 
>>>>> If I wanted to access them from the same module I would make them package public.
>>>> It's a feature -- a replacement for "friend" in C++. The general idea of
>>>> a module is that it is an autonomous code unit controlled by a single
>>>> developer/team and if you're accessing a private function in the module,
>>>> you have a good reason to. It's all the same file, so if you're changing
>>>> something that accesses a private member, you can change the private
>>>> implementation as well.
>>>> 
>>>> "package" isn't implemented (sadly -- I find it very useful in Java so
>>>> that a package has only a single public API).
>>> 
>>> Ok, thanks for your reply. But I think you've missed one thing. Let's now speak of OO systems, about one basic principle of such systems which is data abstraction. According to it an object should not expose any of its implementation details. This means that you should completely hide the way in which an object implements a message handler from the rest of the program.That's one reason why all of your instance variables (a class's nonconstant fields) should be private.
>>> So what do you think on that D implementation of "private" access specifier breaks data abstraction?
>> 
>> If you implement a single class per module it isn't broken.
>> 
>> By implementing multiple classes in a single module, as previously
>> mentioned you are indicating that you consider the classes part of a
>> single set of "implementation details" which are then hidden from other
>> modules, again not broken.
>> 
>> In this way it allows you to declare the level at which information
>> hiding should be enforced.
> 
> I try to summary what I wanted to ask and say.
> 
> 1) Why D language OO "private" access specifier is made "module public" (e.g. method can be accessed by any other class or function inside the same module, "private" field can be accessed and CHANGED by any other class or function inside the same module)?

private in D means private to the module (file), not to the class, it is just another way of defining it, one that has surprised you but that has some use.

Imagine having two or three classes interacting in something that need access (for efficiency reasons) to internal implementation details, or a function combine(a,b,c) that need access to details of all of them.
If a,b,c have the same type you can have a.combine(b,c) but it might be uglier and with less symmetry... so you can write combine(a,b,c) that calls it (redundancy).

You know internal details might be the fact that you use a stack based storage, and for most operations this is not important and you want to keep it that way, but some operations are much more efficient if you do use that knowledge...

It is *good* is you can break the rules in some occasions, while still keeping everything as it should be.

> -- To my point of view if you want to implement such a communication is a single module between two classes or a function and a class just make "module public" access specifier, "private" should be private (e.g. restricts the access to the class itself. Only methods that are part of the same class can access private members.)

well if you can have free standing functions or variables what means private for them? This way private always means the same thing, you don't need too many concepts and you don't loose much (a language has *always* tradeoffs)

> 
> 2) What's the difference between module and package?

module= file
(or at least it should be)

package= group of modules=directory

> 
> -- Maybe that's where I'm wrong, because it is the same things to me.

Reply to DF,

> It is easy to say that it's ok, than find out why it is ok.
> 
> I'm not saying that D implementation of "private" access specifier is
> wrong, I just want to know why "private" is implemented in this way.
> 
> Is it just because it solves language-specific problems or there is
> any other reason for that?
> 

You are asserting that encapsulation should be at the class level.
D chose to implement it at the module (file) level.

Aside from that distinction do you have any issues with the way it is implemented?

A side note, would you have issues with nested classes having access to enclosing class variables or the other way around?
There is good arguments for allowing or denying just about any class of access, setting up an access control system that can cover all of them is impractical. Therefor you get to pick and chose.

Jesse Phillips wrote:
> On Thu, 21 Aug 2008 07:11:15 -0400, DF wrote:
> 
>> Neil Vice Wrote:
>>
>>> DF wrote:
>>>> Robert Fraser Wrote:
>>>>
>>>>> DF wrote:
>>>>>> Why can private fields be accessed from other methods or classes in the same module?
>>>>>>
>>>>>> If I wanted to access them from the same module I would make them package public.
>>>>> It's a feature -- a replacement for "friend" in C++. The general idea of a module is that it is an autonomous code unit controlled by a single developer/team and if you're accessing a private function in the module, you have a good reason to. It's all the same file, so if you're changing something that accesses a private member, you can change the private implementation as well.
>>>>>
>>>>> "package" isn't implemented (sadly -- I find it very useful in Java so that a package has only a single public API).
>>>> Ok, thanks for your reply. But I think you've missed one thing. Let's now speak of OO systems, about one basic principle of such systems which is data abstraction. According to it an object should not expose any of its implementation details. This means that you should completely hide the way in which an object implements a message handler from the rest of the program.That's one reason why all of your instance variables (a class's nonconstant fields) should be private. So what do you think on that D implementation of "private" access specifier breaks data abstraction?
>>> If you implement a single class per module it isn't broken.
>>>
>>> By implementing multiple classes in a single module, as previously mentioned you are indicating that you consider the classes part of a single set of "implementation details" which are then hidden from other modules, again not broken.
>>>
>>> In this way it allows you to declare the level at which information hiding should be enforced.
>> I try to summary what I wanted to ask and say.
>>
>> 1) Why D language OO "private" access specifier is made "module public" (e.g. method can be accessed by any other class or function inside the same module, "private" field can be accessed and CHANGED by any other class or function inside the same module)?
>>
>> -- To my point of view if you want to implement such a communication is a single module between two classes or a function and a class just make "module public" access specifier, "private" should be private (e.g. restricts the access to the class itself. Only methods that are part of the same class can access private members.)
>>
>> 2) What's the difference between module and package?
>>
>> -- Maybe that's where I'm wrong, because it is the same things to me.
> 
> A module is a single file, a package is all the files in that directory.
> 
> You are claiming that breaking the strict model laid out by Java, breaks OOP.

Technically speaking OOP is a paradigm and no jargon is really concrete.
 It's fun to experiment with different implementations and see how they
work out.

Lars Ivar Igesund wrote:
> Robert Fraser wrote:
> 
>> DF wrote:
>>> Why can private fields be accessed from other methods or classes in the
>>> same module?
>>>
>>> If I wanted to access them from the same module I would make them package
>>> public.
>> It's a feature -- a replacement for "friend" in C++. The general idea of
>> a module is that it is an autonomous code unit controlled by a single
>> developer/team and if you're accessing a private function in the module,
>> you have a good reason to. It's all the same file, so if you're changing
>> something that accesses a private member, you can change the private
>> implementation as well.
>>
>> "package" isn't implemented (sadly -- I find it very useful in Java so
>> that a package has only a single public API).
> 
> package is implemented to mean that something is accessible to other modules
> in the same package.

I meant that (last I checked), DMD doesn't enforce it.

"Robert Fraser" <fraserofthenight@gmail.com> wrote in message news:g8kh4k$5jc$1@digitalmars.com...
> Lars Ivar Igesund wrote:
>> Robert Fraser wrote:
>>
>>> DF wrote:
>>>> Why can private fields be accessed from other methods or classes in the same module?
>>>>
>>>> If I wanted to access them from the same module I would make them
>>>> package
>>>> public.
>>> It's a feature -- a replacement for "friend" in C++. The general idea of a module is that it is an autonomous code unit controlled by a single developer/team and if you're accessing a private function in the module, you have a good reason to. It's all the same file, so if you're changing something that accesses a private member, you can change the private implementation as well.
>>>
>>> "package" isn't implemented (sadly -- I find it very useful in Java so that a package has only a single public API).
>>
>> package is implemented to mean that something is accessible to other
>> modules
>> in the same package.
>
> I meant that (last I checked), DMD doesn't enforce it.

For a long time that was true but it has seemed to more or less enforce it since about 1.0.  I think there may still be some bugs with more complex cases but it does seem to work for the basic case.

Fawzi Mohamed Wrote:

> Imagine having two or three classes interacting in something that need access (for efficiency reasons) to internal implementation detail

C# achieves this using the internal qualifier:

  http://msdn.microsoft.com/en-us/library/ba0a1yw2(VS.80).aspx

which allows it to retain the 'more standard' meaning for the private qualifier.

Jussi Jumppanen a écrit :
> Fawzi Mohamed Wrote:
> 
>> Imagine having two or three classes interacting in something that need access (for efficiency reasons) to internal implementation detail
> 
> C# achieves this using the internal qualifier: 
> 
>   http://msdn.microsoft.com/en-us/library/ba0a1yw2(VS.80).aspx
> 
> which allows it to retain the 'more standard' meaning for
> the private qualifier.

Actually, "internal" is C# is a lot more than D's "private": the entire assembly may see the internal symbol. That's quite not private, for me. :-P

On Thu, 21 Aug 2008 18:47:39 +0300, Max Samukha wrote:

> On Thu, 21 Aug 2008 14:08:04 +0000 (UTC), Jesse Phillips
> <jessekphillips@gmail.com> wrote:
> 
> 
>>An unnecessarily complex/bad design forced by Java? Easy Hello World.
>>
>>public static void main(String[] args) {
>>     System.out.println("Hello World");
>>}
>>
>>
>>My main class is within an object, which is required to be static.
>> That is just horrible. In general the class that includes main is a bad place
>>to put anything, it is usually a run method or something that does a bunch of work. The problem is that it is forcing a procedural function(s) into the OOP world.
> 
> This has nothing to do with design but rather syntax.
> 
> Please, don't put forward this very argument. I may argue that D's modules are essentially limited final classes with only static members. Or static classes. Or singleton objects. Even D spec says "Modules superficially resemble classes".

Ok you got me, but you have to admit that if you designed something procedurally in Java you would be accused of poor design even if done correctly.

"DF" <deefriend@ymail.com> wrote in message news:g8jpsg$18mv$1@digitalmars.com...
>>
>> Lars Ivar Igesund
>> blog at http://larsivi.net
>> DSource, #d.tango & #D: larsivi
>> Dancing the Tango
>
> It is easy to say that it's ok, than find out why it is ok.
> I'm not saying that D implementation of "private" access specifier is
> wrong, I just want to know why "private" is implemented in this way.
> Is it just because it solves language-specific problems or there is any
> other reason for that?

I think the point is that it allows you to have two (or more) classes that are entirely visible to each other, but *without being visible to everything else.*

It allows you to encapsulate a collection of classes / functions.

For example, you might have some linked list / binary tree type structure with different kinds of nodes represented by different classes. If you declare all these classes in one module you can actualy hide more of the implementation because methods that might only ever be called between these classes themselves, need not be visible outside the unit.

Without this mechanism they'd need to be public / package to be visible between nodes. And hence that makes them more visible to other parts aswell.

DF Wrote:

> Neil Vice Wrote:
> 
> > DF wrote:
> > > Robert Fraser Wrote:
> > > 
> > >> DF wrote:
> > >>> Why can private fields be accessed from other methods or classes in the same module?
> > >>>
> > >>> If I wanted to access them from the same module I would make them package public.
> > >> It's a feature -- a replacement for "friend" in C++. The general idea of a module is that it is an autonomous code unit controlled by a single developer/team and if you're accessing a private function in the module, you have a good reason to. It's all the same file, so if you're changing something that accesses a private member, you can change the private implementation as well.
> > >>
> > >> "package" isn't implemented (sadly -- I find it very useful in Java so that a package has only a single public API).
> > > 
> > > Ok, thanks for your reply. But I think you've missed one thing. Let's now speak of OO systems, about one basic principle of such systems which is data abstraction. According to it an object should not expose any of its implementation details. This means that you should completely hide the way in which an object implements a message handler from the rest of the program.That's one reason why all of your instance variables (a class's nonconstant fields) should be private.
> > > So what do you think on that D implementation of "private" access specifier breaks data abstraction?
> > 
> > If you implement a single class per module it isn't broken.
> > 
> > By implementing multiple classes in a single module, as previously mentioned you are indicating that you consider the classes part of a single set of "implementation details" which are then hidden from other modules, again not broken.
> > 
> > In this way it allows you to declare the level at which information hiding should be enforced.
> 
> I try to summary what I wanted to ask and say.
> 
> 1) Why D language OO "private" access specifier is made "module public" (e.g. method can be accessed by any other class or function inside the same module, "private" field can be accessed and CHANGED by any other class or function inside the same module)?
> 
> -- To my point of view if you want to implement such a communication is a single module between two classes or a function and a class just make "module public" access specifier, "private" should be private (e.g. restricts the access to the class itself. Only methods that are part of the same class can access private members.)
> 
> 2) What's the difference between module and package?
> 
> -- Maybe that's where I'm wrong, because it is the same things to me.

Thanks for your replies, guys. Just one last thing to ask. Is there a way to have private field in a class, that is and will be private only in this class, no matter what changes I will make in my module?
(Here I mean private - private to the class not to the module).