Object Oriented Programming with D Language. Private access specifier.

Lars Ivar Igesund larsivar at igesund.net
Thu Aug 21 06:48:30 PDT 2008


DF wrote:

> Lars Ivar Igesund Wrote:
> 
>> 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.
>> 
>> I see no need to do that, you are the one claiming that D is at fault
>> which is at the core of this thread.
>> 
>> --
>> 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?

Modules in D are an entity by itself (with some limited use as a way of
encapsulation), and so you should expect stuff inside that entity to be
able to acess other stuff there. Saying that it is private only restricts
readers from other modules. There could be potential to interpret it the
way you want, but C++' friend functionality (which I at least find useful)
was an inspiration for this particular design in D, and I am glad it is
this way.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango



More information about the Digitalmars-d mailing list