Object Oriented Programming with D Language. Private access specifier. Summary.

[Jesse Phillips]

On Thu, 21 Aug 2008 07:11:15 -0400, DF wrote:

> Neil Vice Wrote:
> 
>> DF 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).
>> > 
>> > 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?
>> 
>> If you implement a single class per module it isn't broken.
>> 
>> By implementing multiple classes in a single module, as previously
>> mentioned you are indicating that you consider the classes part of a
>> single set of "implementation details" which are then hidden from other
>> modules, again not broken.
>> 
>> In this way it allows you to declare the level at which information
>> hiding should be enforced.
> 
> 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)?
> 
> -- 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.)
> 
> 2) What's the difference between module and package?
> 
> -- Maybe that's where I'm wrong, because it is the same things to me.

A module is a single file, a package is all the files in that directory.

You are claiming that breaking the strict model laid out by Java, breaks 
OOP. D is procedural, OOP, others, as the programmer working on a class I 
have full control over it in that file. I don't think I should be limited 
as to what I can do with especially when I do want to limit outsiders 
(grated if you are editing within a package you probably can edit the 
module too)

Consider this though. You have claimed that if you are accessing from out 
side the OOP model, you are designing your code wrong. For one thing that 
is my choice, but consider this. If you are writing code in you module 
that shouldn't have access to the functions/member data in the class you 
are structuring your modules and packages wrong.