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

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.

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

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

C# achieves this using the internal qualifier: 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

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

Actually, "internal" is C# is a lot more than D's "private": the entire 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,

 Actually, "internal" is C# is a lot more than D's "private": the
 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 "Chris R. Miller" <lordSaurontheGreat gmail.com> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=






 the same module?

 If I wanted to access them from the same module I would make them
 package public.

idea of a module is that it is an autonomous code unit controlled b=





 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=





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





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





 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?

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=



 modules, again not broken.

 In this way it allows you to declare the level at which information
 hiding should be enforced.

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=


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


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


 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=

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

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

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

I think c# and Delphi have the qualifier "strict private", which does in 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 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 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.

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

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?

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

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

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.

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.

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 next sibling parent 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.

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
prev sibling next sibling parent 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

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
prev sibling parent 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