Object Oriented Programming with D Language. Private access specifier.

[DF]

Fawzi Mohamed Wrote:

> On 2008-08-21 09:59:35 +0200, DF <deefriend at 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.