I'm sure most of you, having read the manual, will know this already, but I thought it worth giving it a mention. There is a way, in D, of making something so super-private, that even code in the same source-file can't see it.

You just do this:

>       class A
>       {
>          class B
>          {
>              // B stuff
>          }
>
>          // A stuff
>       }

B is now super-private. Seen from outside the scope of class A {...}, it's just not there.

I utilised this trick in implementing my Bool type. It worked a treat.

Arcane Jill

Guess I'm missing something obvious, but I cannot find nested classes documented at all. Even the syntax definition does not contain that possibility, if I read it correctly ("ClassBodyDeclaration" contains "Declaration", but I don't see that "Declaration" contains "ClassDeclaration")


Arcane Jill wrote:

> I'm sure most of you, having read the manual, will know this already, but I thought it worth giving it a mention. There is a way, in D, of making something so super-private, that even code in the same source-file can't see it.
> 
> You just do this:
> 
>>       class A
>>       {
>>          class B
>>          {
>>              // B stuff
>>          }
>>
>>          // A stuff
>>       }
> 
> B is now super-private. Seen from outside the scope of class A {...}, it's just not there.
> 
> I utilised this trick in implementing my Bool type. It worked a treat.
> 
> Arcane Jill

In article <c9nn49$a3m$1@digitaldaemon.com>, Norbert Nemec says...
>
>Guess I'm missing something obvious, but I cannot find nested classes documented at all. Even the syntax definition does not contain that possibility, if I read it correctly ("ClassBodyDeclaration" contains "Declaration", but I don't see that "Declaration" contains "ClassDeclaration")

I can't remember where I read it, and I can't find it now. I can vaguely remember Walter saying that D has nested classes but not inner classes (or words to that effect).

I hope it's a feature and not an accident. If Walter decides it's a bug and fixes it, my code will stop working!

But it does work - at least, with the current compiler. Jill

In article <c9noh9$c5v$1@digitaldaemon.com>, Arcane Jill says...
>
>I can't remember where I read it, and I can't find it now. I can vaguely remember Walter saying that D has nested classes but not inner classes (or words to that effect).

I remember a posting like that as well.  Anyway, it's in black-and-white (red-and-green if you will) on the language comparison chart: http://www.digitalmars.com/d/comparison.html

In case anyone is curious about the difference, I found the following (java) article that explains the differences.  (I had to satisfy my curiosity on this one, since the exact details of inner and outer classes escaped me.)

http://www.javaworld.com/javaworld/javatips/jw-javatip75.html:

Nested classes vs. inner classes
Nested classes are simply static inner classes. The difference between nested
classes and inner classes is the same as the difference between static and
nonstatic members of a class: nested classes are associated with the enclosing
class itself, whereas inner classes are associated with an object of the
enclosing class.

Because of this, inner class objects require an object of the enclosing class, while nested class objects do not. Nested classes, therefore, behave just like top-level classes, using the enclosing class to provide a package-like organization. In addition, nested classes have access to all members of the enclosing class.

"EricAnderton at yahoo dot com" <EricAnderton_member@pathlink.com> wrote in message news:c9npn6$e22$1@digitaldaemon.com...
> In article <c9noh9$c5v$1@digitaldaemon.com>, Arcane Jill says...
> >
> >I can't remember where I read it, and I can't find it now. I can vaguely remember Walter saying that D has nested classes but not inner classes
(or words
> >to that effect).
>
> I remember a posting like that as well.  Anyway, it's in black-and-white (red-and-green if you will) on the language comparison chart: http://www.digitalmars.com/d/comparison.html

It seams natural to me that D has nested classes because i have used them but i'm surprised that they aren't mentioned anywhere!

> In case anyone is curious about the difference, I found the following
(java)
> article that explains the differences.  (I had to satisfy my curiosity on
this
> one, since the exact details of inner and outer classes escaped me.)

I remember those discussions about inner classes, because i thought they would be a good solution to a design problem i was having.

The situation was:
I had classes(for example) A, B, C, D. And A was on the top, the
only class visible from outside of the module, and in it i created instances
of B, C, D and i needed access to A from these classes. It seamed to
me that passing a reference to A to all B,C and D constructors was
a lot of work which inner classes could solve.

But eventually i found a rather elegant solution: In the module
i declared a global private:
A theA; // a reference to object A

And then in every public function of A that is accessed from outside
of the module i do:
theA = this;

And then every B,C,D object just uses theA and class A makes sure to set it to the right value.

This is in some ways maybe even a better solution than that with
inner classes, because with inner classes every inner object
will internally have to hold the reference to the enclosing class.


> http://www.javaworld.com/javaworld/javatips/jw-javatip75.html:
>
> Nested classes vs. inner classes
> Nested classes are simply static inner classes. The difference between
nested
> classes and inner classes is the same as the difference between static and nonstatic members of a class: nested classes are associated with the
enclosing
> class itself, whereas inner classes are associated with an object of the enclosing class.
>
> Because of this, inner class objects require an object of the enclosing
class,
> while nested class objects do not. Nested classes, therefore, behave just
like
> top-level classes, using the enclosing class to provide a package-like organization. In addition, nested classes have access to all members of
the
> enclosing class.
>
>

In article <c9npn6$e22$1@digitaldaemon.com>, EricAnderton at yahoo dot com says...
>
>In article <c9noh9$c5v$1@digitaldaemon.com>, Arcane Jill says...
>>
>>I can't remember where I read it, and I can't find it now. I can vaguely remember Walter saying that D has nested classes but not inner classes (or words to that effect).
>
>I remember a posting like that as well.  Anyway, it's in black-and-white (red-and-green if you will) on the language comparison chart: http://www.digitalmars.com/d/comparison.html
>
>In case anyone is curious about the difference, I found the following (java) article that explains the differences.  (I had to satisfy my curiosity on this one, since the exact details of inner and outer classes escaped me.)
>
>http://www.javaworld.com/javaworld/javatips/jw-javatip75.html:
>
>Nested classes vs. inner classes
>Nested classes are simply static inner classes. The difference between nested
>classes and inner classes is the same as the difference between static and
>nonstatic members of a class: nested classes are associated with the enclosing
>class itself, whereas inner classes are associated with an object of the
>enclosing class.
>
>Because of this, inner class objects require an object of the enclosing class, while nested class objects do not. Nested classes, therefore, behave just like top-level classes, using the enclosing class to provide a package-like organization. In addition, nested classes have access to all members of the enclosing class.

In the last sentence, you mean "inner classes have access...", since you would have to be associated with an outer object to find those members, right?

Kevin

Arcane Jill wrote:

> In article <c9nn49$a3m$1@digitaldaemon.com>, Norbert Nemec says...
>>
>>Guess I'm missing something obvious, but I cannot find nested classes documented at all. Even the syntax definition does not contain that possibility, if I read it correctly ("ClassBodyDeclaration" contains "Declaration", but I don't see that "Declaration" contains "ClassDeclaration")
> 
> I can't remember where I read it, and I can't find it now. I can vaguely remember Walter saying that D has nested classes but not inner classes (or words to that effect).
> 
> I hope it's a feature and not an accident. If Walter decides it's a bug and fixes it, my code will stop working!

I'm pretty sure that nested classes are a feature, but the question of privacy that you raised with your original post is absolutely unclear to me. That's why I took at look at the specs: I don't see any reason why your example should give any effect of "super-private private" as you call it.

In article <c9mjfa$1nlr$1@digitaldaemon.com>, Arcane Jill says...
>
>I'm sure most of you, having read the manual, will know this already, but I thought it worth giving it a mention. There is a way, in D, of making something so super-private, that even code in the same source-file can't see it.
>
>You just do this:
>
>>       class A
>>       {
>>          class B
>>          {
>>              // B stuff
>>          }
>>
>>          // A stuff
>>       }
>
>B is now super-private. Seen from outside the scope of class A {...}, it's just not there.
>
>I utilised this trick in implementing my Bool type. It worked a treat.
>
>Arcane Jill
>
>

(probably I'm just raising another non-issue :p )

Walter!,
people are already using constructs for a purpouse other
then the intendend by the language!
Many times that shows the strenghs of the concepts.
Here I think it's showing some kind of limitation...

Why is there a necessity to do this in an indirect way?
How can it be corrected?

Ant

Ivan Senji wrote:
> But eventually i found a rather elegant solution: In the module
> i declared a global private:
> A theA; // a reference to object A
> 
> And then in every public function of A that is accessed from outside
> of the module i do:
> theA = this;
> 
> And then every B,C,D object just uses theA and class A makes sure
> to set it to the right value.
> 
> This is in some ways maybe even a better solution than that with
> inner classes, because with inner classes every inner object
> will internally have to hold the reference to the enclosing class.

This doesn't seem very threadsafe. And if you forget to add theA = this; at any place in A, you will get hidden and hard to find bugs. Seems
like adding a reference to the "outer" class is safer in all respects.
Or am I wrong?

/Oskar

"Oskar Linde" <d98-oliRE.MO.VE@nada.kth.se> wrote in message news:c9ob7j$18b2$1@digitaldaemon.com...
> Ivan Senji wrote:
> > But eventually i found a rather elegant solution: In the module
> > i declared a global private:
> > A theA; // a reference to object A
> >
> > And then in every public function of A that is accessed from outside
> > of the module i do:
> > theA = this;
> >
> > And then every B,C,D object just uses theA and class A makes sure to set it to the right value.
> >
> > This is in some ways maybe even a better solution than that with
> > inner classes, because with inner classes every inner object
> > will internally have to hold the reference to the enclosing class.
>
> This doesn't seem very threadsafe. And if you forget to add theA = this; at any place in A, you will get hidden and hard to find bugs. Seems like adding a reference to the "outer" class is safer in all respects. Or am I wrong?

Threadsafety! I didn't think of that, and you are 100% right! But
i think it can be fixed easilly because there aren't many methods from
A that can be called from the outside, so i could wrap their
code in  a synchronized block. Would this help?

Adding a reference everywhere is safer, and that is what i initially did. But if you have a class with 3 shorts and create thousands of them, those 4 bytes seamed to much to have for every one.

> /Oskar