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.

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

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?

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

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

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.

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.

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

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

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' :)