www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Object Oriented Programming with D Language. Private access specifier.

reply DF <deefriend ymail.com> writes:
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.
Aug 20 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
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).
Aug 20 2008
next sibling parent reply DF <deefriend ymail.com> writes:
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?
Aug 21 2008
next sibling parent reply Neil Vice <sardonicpresence gmail.com> writes:
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.
Aug 21 2008
parent reply DF <deefriend ymail.com> writes:
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.
Aug 21 2008
next sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
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.
Aug 21 2008
parent "Chris R. Miller" <lordSaurontheGreat gmail.com> writes:
Jesse Phillips wrote:

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

 Neil Vice Wrote:


 DF wrote:

 Robert Fraser Wrote:


 DF wrote:

 Why can private fields be accessed from other methods or classes i=












n

 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 b=










y

 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, s=










o

 if you're changing something that accesses a private member, you ca=










n

 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 oth=






er

 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 i=




s

 a single module between two classes or a function and a class just mak=




e

 "module public" access specifier, "private" should be private (e.g.
 restricts the access to the class itself. Only methods that are part o=




f

 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.


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


=2E

=20
 You are claiming that breaking the strict model laid out by Java, break=


s=20

 OOP.


Technically speaking OOP is a paradigm and no jargon is really concrete.
 It's fun to experiment with different implementations and see how they
work out.
Aug 21 2008
prev sibling next sibling parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2008-08-21 13:11:15 +0200, DF <deefriend ymail.com> said:


 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)?


private in D means private to the module (file), not to the class, it 
is just another way of defining it, one that has surprised you but that 
has some use.

Imagine having two or three classes interacting in something that need 
access (for efficiency reasons) to internal implementation details, or 
a function combine(a,b,c) that need access to details of all of them.
If a,b,c have the same type you can have a.combine(b,c) but it might be 
uglier and with less symmetry... so you can write combine(a,b,c) that 
calls it (redundancy).

You know internal details might be the fact that you use a stack based 
storage, and for most operations this is not important and you want to 
keep it that way, but some operations are much more efficient if you do 
use that knowledge...

It is *good* is you can break the rules in some occasions, while still 
keeping everything as it should be.


 -- 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.)


well if you can have free standing functions or variables what means 
private for them? This way private always means the same thing, you 
don't need too many concepts and you don't loose much (a language has 
*always* tradeoffs)


 
 2) What's the difference between module and package?


module= file
(or at least it should be)

package= group of modules=directory


 
 -- Maybe that's where I'm wrong, because it is the same things to me.
Aug 21 2008
parent reply Jussi Jumppanen <jussij zeusedit.com> writes:
Fawzi Mohamed Wrote:


 Imagine having two or three classes interacting in 
 something that need access (for efficiency reasons) 
 to internal implementation detail




  http://msdn.microsoft.com/en-us/library/ba0a1yw2(VS.80).aspx

which allows it to retain the 'more standard' meaning for
the private qualifier.
Aug 21 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Jussi Jumppanen a écrit :

 Fawzi Mohamed Wrote:
 

 Imagine having two or three classes interacting in 
 something that need access (for efficiency reasons) 
 to internal implementation detail


 

 
   http://msdn.microsoft.com/en-us/library/ba0a1yw2(VS.80).aspx
 
 which allows it to retain the 'more standard' meaning for
 the private qualifier.



assembly may see the internal symbol. That's quite not private, for me. :-P
Aug 21 2008
parent =?iso-8859-1?Q?Julio=20C=e9sar=20Carrascal=20Urquijo?= <jcarrascal gmail.com> writes:
Hello Ary,



 entire assembly may see the internal symbol. That's quite not private,
 for me. :-P
 


And other assemblies referenced with the [assembly: InternalsVisibleTo()] 
attribute can see "internal" symbols.
Aug 22 2008
prev sibling next sibling parent reply DF <deefriend ymail.com> writes:
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.


Thanks for your replies, guys. Just one last thing to ask. Is there a way to
have private field in a class, that is and will be private only in this class,
no matter what changes I will make in my module?
(Here I mean private - private to the class not to the module).
Aug 21 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"DF" <deefriend ymail.com> wrote in message 
news:g8ln06$3097$1 digitalmars.com...


 Thanks for your replies, guys. Just one last thing to ask. Is there a way 
 to have private field in a class, that is and will be private only in this 
 class, no matter what changes I will make in my module?
 (Here I mean private - private to the class not to the module).


Put the class in its own module ;)
Aug 22 2008
parent "Jb" <jb nowhere.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:g8mbbp$1doh$1 digitalmars.com...

 "DF" <deefriend ymail.com> wrote in message 
 news:g8ln06$3097$1 digitalmars.com...


 Thanks for your replies, guys. Just one last thing to ask. Is there a way 
 to have private field in a class, that is and will be private only in 
 this class, no matter what changes I will make in my module?
 (Here I mean private - private to the class not to the module).


 Put the class in its own module ;)



fact make it absolutely private to that class, rather than still visible to 
other classes in the same module / unit.

Maybe D would benefit from that also.
Aug 22 2008
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
DF wrote:

...

 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)?


My 2 cents is that your assumption that private is exclusively related to OO
programming is wrong. Private provides encapsulation, but that is not
restricted to OO programming. As has been said, it is on the module level,
not coincidentally corresponding to a single file. 
 

 -- 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.)


In D it should be done the other way around: if you want to restrict private
access to a single class, design your modules to use one class per file.
 

 2) What's the difference between module and package?
 
 -- Maybe that's where I'm wrong, because it is the same things to me.


They are not the same, a module corresponds to a file, a package corresponds
to one directory containing a set of modules.
Aug 22 2008
parent Lutger <lutger.blijdestijn gmail.com> writes:
Lutger wrote:

.. 

 My 2 cents is that your assumption that private is exclusively related to
 OO programming is wrong. Private provides encapsulation, but that is not
 restricted to OO programming. As has been said, it is on the module level,
 not coincidentally corresponding to a single file.


Just to clarify: encapsulation helps modular programming. D supports this
directly, most common OOP languages emulate that by the use of classes. I
thinks it makes more sense the way it's done in D.
Aug 22 2008
prev sibling parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2008-08-21 09:59:35 +0200, DF <deefriend 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
Aug 21 2008
parent reply DF <deefriend ymail.com> writes:
Fawzi Mohamed Wrote:


 On 2008-08-21 09:59:35 +0200, DF <deefriend 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.
Aug 21 2008
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
DF wrote:


 Fawzi Mohamed Wrote:
 

 On 2008-08-21 09:59:35 +0200, DF <deefriend 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
Aug 21 2008
parent reply DF <deefriend ymail.com> writes:
Lars Ivar Igesund Wrote:


 DF wrote:
 

 Fawzi Mohamed Wrote:
 

 On 2008-08-21 09:59:35 +0200, DF <deefriend 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.
Aug 21 2008
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
DF wrote:


 Lars Ivar Igesund Wrote:
 

 DF wrote:
 

 Fawzi Mohamed Wrote:
 

 On 2008-08-21 09:59:35 +0200, DF <deefriend 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
Aug 21 2008
parent reply DF <deefriend ymail.com> writes:
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 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?
Aug 21 2008
next sibling parent superdan <super dan.org> writes:
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 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."
Aug 21 2008
prev sibling next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
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 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
Aug 21 2008
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to DF,


 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?
 


You are asserting that encapsulation should be at the class level.
D chose to implement it at the module (file) level.

Aside from that distinction do you have any issues with the way it is
implemented?

A side note, would you have issues with nested classes having access to
enclosing 
class variables or the other way around?
There is good arguments for allowing or denying just about any class of access, 
setting up an access control system that can cover all of them is impractical. 
Therefor you get to pick and chose.
Aug 21 2008
prev sibling parent "Jb" <jb nowhere.com> writes:
"DF" <deefriend ymail.com> wrote in message 
news:g8jpsg$18mv$1 digitalmars.com...

 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?


I think the point is that it allows you to have two (or more) classes that 
are entirely visible to each other, but *without being visible to everything 
else.*

It allows you to encapsulate a collection of classes / functions.

For example, you might have some linked list / binary tree type structure 
with different kinds of nodes represented by different classes. If you 
declare all these classes in one module you can actualy hide more of the 
implementation because methods that might only ever be called between these 
classes themselves, need not be visible outside the unit.

Without this mechanism they'd need to be public / package to be visible 
between nodes. And hence that makes them more visible to other parts aswell.
Aug 21 2008
prev sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
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 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.
Aug 21 2008
parent reply Max Samukha <samukha voliacable.com.removethis> writes:
On Thu, 21 Aug 2008 14:08:04 +0000 (UTC), Jesse Phillips
<jessekphillips gmail.com> wrote:


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.


This has nothing to do with design but rather syntax.

Please, don't put forward this very argument. I may argue that D's
modules are essentially limited final classes with only static
members. Or static classes. Or singleton objects. Even D spec says
"Modules superficially resemble classes".
Aug 21 2008
parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Thu, 21 Aug 2008 18:47:39 +0300, Max Samukha wrote:


 On Thu, 21 Aug 2008 14:08:04 +0000 (UTC), Jesse Phillips
 <jessekphillips gmail.com> wrote:
 
 

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.


 
 This has nothing to do with design but rather syntax.
 
 Please, don't put forward this very argument. I may argue that D's
 modules are essentially limited final classes with only static members.
 Or static classes. Or singleton objects. Even D spec says "Modules
 superficially resemble classes".


Ok you got me, but you have to admit that if you designed something 
procedurally in Java you would be accused of poor design even if done 
correctly.
Aug 21 2008
parent Max Samukha <samukha voliacable.com.removethis> writes:
On Fri, 22 Aug 2008 01:23:13 +0000 (UTC), Jesse Phillips
<jessekphillips gmail.com> wrote:



Ok you got me, but you have to admit that if you designed something 
procedurally in Java you would be accused of poor design even if done 
correctly.


I admit that
Aug 22 2008
prev sibling parent reply Jacob Carlborg <doobnet gmail.com> writes:
DF wrote:

 Fawzi Mohamed Wrote:
 

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


In Java you can have several classes in the same file and they have 
access to each others private members, it's called inner classes. It's 
useful for listeners for example.
Aug 22 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
Jacob Carlborg wrote:

 In Java you can have several classes in the same file and they have 
 access to each others private members, it's called inner classes. It's 
 useful for listeners for example.


Java requires you to use classes for anything that has structure or 
anything that can do anything. You can't have two top-level classes in 
one file, though; you need another class to act as a namespace for them.

And using inner classes for events is ugly. I implemented an event 
broker in Java, but I couldn't stand using it because I had to use inner 
classes to get anything done.
Aug 22 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Christopher Wright wrote:

 You can't have two top-level classes in 
 one file, though; you need another class to act as a namespace for them.
 


Surprisingly, you can have more than one top-level class in a Java file. 
    But only one can be public, the others have default protection, and 
are not accessible from outside the file.
(I've only found this out recently, some months ago, even though I've 
programming in Java for quite longer)


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Aug 25 2008
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
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).


package is implemented to mean that something is accessible to other modules
in the same package.


-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Aug 21 2008
next sibling parent reply Max Samukha <samukha voliacable.com.removethis> writes:
On Thu, 21 Aug 2008 10:34:29 +0200, Lars Ivar Igesund
<larsivar igesund.net> 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).


package is implemented to mean that something is accessible to other modules
in the same package.


It would be even more useful if members with package accesibility were
accessible not only from the same package but also from its
subpackages.

Imagine there is a function, data structure or whatever that is used
throughout a complex package containing nested packages but is not
intended to be accessible by users of this package. Now I have to
declare such a function/structure public. 'package' does not help me
here.
Aug 21 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Max Samukha" <samukha voliacable.com.removethis> wrote in message 
news:9sjqa4t9eta17lpab2jrnifpigsdhgm1t6 4ax.com...

 It would be even more useful if members with package accesibility were
 accessible not only from the same package but also from its
 subpackages.

 Imagine there is a function, data structure or whatever that is used
 throughout a complex package containing nested packages but is not
 intended to be accessible by users of this package. Now I have to
 declare such a function/structure public. 'package' does not help me
 here.


I've always felt the same way.  I end up designing all my libraries one 
level deep because of this "feature."  It'd be nice if I could group modules 
into subpackages which operate as a unit, which also increases privacy 
granularity (that is, "package" symbols in one part of the library are not 
visible everywhere).
Aug 21 2008
parent Max Samukha <samukha voliacable.com.removethis> writes:
On Thu, 21 Aug 2008 10:48:32 -0400, "Jarrett Billingsley"
<kb3ctd2 yahoo.com> wrote:


"Max Samukha" <samukha voliacable.com.removethis> wrote in message 
news:9sjqa4t9eta17lpab2jrnifpigsdhgm1t6 4ax.com...

 It would be even more useful if members with package accesibility were
 accessible not only from the same package but also from its
 subpackages.

 Imagine there is a function, data structure or whatever that is used
 throughout a complex package containing nested packages but is not
 intended to be accessible by users of this package. Now I have to
 declare such a function/structure public. 'package' does not help me
 here.


I've always felt the same way.  I end up designing all my libraries one 
level deep because of this "feature."  It'd be nice if I could group modules 
into subpackages which operate as a unit, which also increases privacy 
granularity (that is, "package" symbols in one part of the library are not 
visible everywhere). 


We need transitive 'package' :)
Aug 21 2008
prev sibling parent reply Jacob Carlborg <doobnet gmail.com> writes:
Max Samukha wrote:

 On Thu, 21 Aug 2008 10:34:29 +0200, Lars Ivar Igesund
 <larsivar igesund.net> 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).


 package is implemented to mean that something is accessible to other modules
 in the same package.


 
 It would be even more useful if members with package accesibility were
 accessible not only from the same package but also from its
 subpackages.
 
 Imagine there is a function, data structure or whatever that is used
 throughout a complex package containing nested packages but is not
 intended to be accessible by users of this package. Now I have to
 declare such a function/structure public. 'package' does not help me
 here.


Could "protected" help here? BTW what happened with "protected"? It's 
not listed here under protection: 
http://www.digitalmars.com/d/1.0/class.html

"protected" works at least with gdc.
Aug 22 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jacob Carlborg" <doobnet gmail.com> wrote in message 
news:g8ma5l$1b8p$1 digitalmars.com...


 Could "protected" help here? BTW what happened with "protected"? It's not 
 listed here under protection: http://www.digitalmars.com/d/1.0/class.html

 "protected" works at least with gdc.


http://www.digitalmars.com/d/1.0/attribute.html#ProtectionAttribute
Aug 22 2008
parent Jacob Carlborg <doobnet gmail.com> writes:
Jarrett Billingsley wrote:

 "Jacob Carlborg" <doobnet gmail.com> wrote in message 
 news:g8ma5l$1b8p$1 digitalmars.com...
 

 Could "protected" help here? BTW what happened with "protected"? It's not 
 listed here under protection: http://www.digitalmars.com/d/1.0/class.html

 "protected" works at least with gdc.


 
 http://www.digitalmars.com/d/1.0/attribute.html#ProtectionAttribute 
 
 


Ah there it is.
Aug 22 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Lars Ivar Igesund 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).


 
 package is implemented to mean that something is accessible to other modules
 in the same package.


I meant that (last I checked), DMD doesn't enforce it.
Aug 21 2008
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:g8kh4k$5jc$1 digitalmars.com...

 Lars Ivar Igesund 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).


 package is implemented to mean that something is accessible to other 
 modules
 in the same package.


 I meant that (last I checked), DMD doesn't enforce it.


For a long time that was true but it has seemed to more or less enforce it 
since about 1.0.  I think there may still be some bugs with more complex 
cases but it does seem to work for the basic case.
Aug 21 2008
prev sibling parent DF <deefriend ymail.com> writes:
Jacob Carlborg Wrote:


 Max Samukha wrote:

 On Thu, 21 Aug 2008 10:34:29 +0200, Lars Ivar Igesund
 <larsivar igesund.net> 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).


 package is implemented to mean that something is accessible to other modules
 in the same package.


 
 It would be even more useful if members with package accesibility were
 accessible not only from the same package but also from its
 subpackages.
 
 Imagine there is a function, data structure or whatever that is used
 throughout a complex package containing nested packages but is not
 intended to be accessible by users of this package. Now I have to
 declare such a function/structure public. 'package' does not help me
 here.


 
 Could "protected" help here? BTW what happened with "protected"? It's 
 not listed here under protection: 
 http://www.digitalmars.com/d/1.0/class.html
 
 "protected" works at least with gdc.


That won't help, if I don't want to have my field in children of a class.
Aug 22 2008