Object Oriented Programming with D Language. Private access specifier. Summary.

[Fawzi Mohamed]

On 2008-08-21 13:11:15 +0200, DF <deefriend at 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.