Object Oriented Programming with D Language. Private access specifier.

[superdan]

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.

good point df. watch out doods, lars `mi is evil' ivar is at it again. gotta love them logic conversations.

df: "proposition_a"
lars: "no. proposition_a is false. to back that up, proposition_b."
df: "could you please provide an example confirming proposition_b?"
lars: "i don't have to do that. you're the one who said proposition_a."