Object Oriented Programming with D Language. Private access specifier.

[Jesse Phillips]

On Thu, 21 Aug 2008 06:25:54 -0400, DF wrote:

> Lars Ivar Igesund Wrote:
> 
>> DF wrote:
>> 
>> > 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.)
>> 
>> OO isn't the answer to everything - and Java's definition of OO is only
>> one interpretation, and not necessarily the best. Java's strictness can
>> in fact force you to unnecessarily complex design aka bad design.
>> 
>> --
>> Lars Ivar Igesund
>> blog at http://larsivi.net
>> DSource, #d.tango & #D: larsivi
>> Dancing the Tango
> 
> "OO isn't the answer to everything" - nobody said that. Just we speak
> about writing OO systems in D language not about that OO is the answer
> to everything. What considers Java I didn't write that Java is the best
> "definition of OO".
> 
> Java's strictness can in fact
> force you to unnecessarily complex design aka bad design - please give
> me an example.

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.