On Fri, 22 Aug 2008 01:23:13 +0000 (UTC), Jesse Phillips
<jessekphillips@gmail.com> wrote:


>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.

I admit that

DF wrote:

...
> 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)?

My 2 cents is that your assumption that private is exclusively related to OO
programming is wrong. Private provides encapsulation, but that is not
restricted to OO programming. As has been said, it is on the module level,
not coincidentally corresponding to a single file.

> -- 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.)

In D it should be done the other way around: if you want to restrict private
access to a single class, design your modules to use one class per file.

> 2) What's the difference between module and package?
> 
> -- Maybe that's where I'm wrong, because it is the same things to me.

They are not the same, a module corresponds to a file, a package corresponds to one directory containing a set of modules.

Lutger wrote:

..
> My 2 cents is that your assumption that private is exclusively related to OO programming is wrong. Private provides encapsulation, but that is not restricted to OO programming. As has been said, it is on the module level, not coincidentally corresponding to a single file.

Just to clarify: encapsulation helps modular programming. D supports this directly, most common OOP languages emulate that by the use of classes. I thinks it makes more sense the way it's done in D.

DF wrote:
> Fawzi Mohamed Wrote:
> 
>> On 2008-08-21 09:59:35 +0200, DF <deefriend@ymail.com> said:
>>
>>> 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?
>> There can be good reasons to break encapsulation (see C++ friend method).
>> A language should make it easy to respect successful practices, support them, but not needlessly limit the programmer.
>> A programmer should be a grown up person, as long as it is clear what is ok and what not, and doing the right thing is easy, all should be well.
>> In Python for example all variables are actually private just by convention...
>>
>> I find D approach very reasonable, it forces all the things that know the private interface to be in one place, namely one file.
>> Suppose that you need to write a template specialization that needs access to private details... D approach is well suited.
>>
>> Fawzi
>>
> 
> Nice reply. "A programmer should be a grown up person..." who told you that? :) Just a joke.
> 
> "There can be good reasons to break encapsulation (see C++ friend method)." - it is sad that you think so.You mixed up a good design solution and a solution. (Here I want to say that PROBABLY you've designed your OO system in a wrong way if you need to break an encapsulation).
> 
> And I don't believe that one can't write "a template specialization that needs access to private details" in Java. (Where "private"  - restricts the access to the class itself. Only methods that are part of the same class can access private members.)
> 
> -- Thanks for your reply. Maybe I am wrong.

In Java you can have several classes in the same file and they have access to each others private members, it's called inner classes. It's useful for listeners for example.

Max Samukha wrote:
> On Thu, 21 Aug 2008 10:34:29 +0200, Lars Ivar Igesund
> <larsivar@igesund.net> 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.
> 
> It would be even more useful if members with package accesibility were
> accessible not only from the same package but also from its
> subpackages.
> 
> Imagine there is a function, data structure or whatever that is used
> throughout a complex package containing nested packages but is not
> intended to be accessible by users of this package. Now I have to
> declare such a function/structure public. 'package' does not help me
> here.

Could "protected" help here? BTW what happened with "protected"? It's not listed here under protection: http://www.digitalmars.com/d/1.0/class.html

"protected" works at least with gdc.

Hello Ary,

> 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
> 

And other assemblies referenced with the [assembly: InternalsVisibleTo()] attribute can see "internal" symbols.

"DF" <deefriend@ymail.com> wrote in message news:g8ln06$3097$1@digitalmars.com...

> 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).

Put the class in its own module ;)

"Jacob Carlborg" <doobnet@gmail.com> wrote in message news:g8ma5l$1b8p$1@digitalmars.com...

> Could "protected" help here? BTW what happened with "protected"? It's not listed here under protection: http://www.digitalmars.com/d/1.0/class.html
>
> "protected" works at least with gdc.

http://www.digitalmars.com/d/1.0/attribute.html#ProtectionAttribute

Jarrett Billingsley wrote:
> "Jacob Carlborg" <doobnet@gmail.com> wrote in message news:g8ma5l$1b8p$1@digitalmars.com...
> 
>> Could "protected" help here? BTW what happened with "protected"? It's not listed here under protection: http://www.digitalmars.com/d/1.0/class.html
>>
>> "protected" works at least with gdc.
> 
> http://www.digitalmars.com/d/1.0/attribute.html#ProtectionAttribute 
> 
> 

Ah there it is.

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:g8mbbp$1doh$1@digitalmars.com...
> "DF" <deefriend@ymail.com> wrote in message news:g8ln06$3097$1@digitalmars.com...
>
>> 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).
>
> Put the class in its own module ;)

I think c# and Delphi have the qualifier "strict private", which does in fact make it absolutely private to that class, rather than still visible to other classes in the same module / unit.

Maybe D would benefit from that also.