www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Super-private private

reply Arcane Jill <Arcane_member pathlink.com> writes:
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
Jun 03 2004
next sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
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
Jun 03 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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
Jun 03 2004
next sibling parent reply EricAnderton at yahoo dot com <EricAnderton_member pathlink.com> writes:
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.
Jun 03 2004
next sibling parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"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.
Jun 03 2004
next sibling parent reply Oskar Linde <d98-oliRE.MO.VE nada.kth.se> writes:
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
Jun 03 2004
parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
"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
Jun 04 2004
prev sibling parent reply EricAnderton at yahoo dot com <EricAnderton_member pathlink.com> writes:
In article <c9ns26$hdl$1 digitaldaemon.com>, Ivan Senji says...
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.
Hrm.. never would have thought to do that myself, but if it works! :) I wonder if there's a way that templates or mixins could be used to make such a design less tedious to maintain? Just a suggestion: You could also do the same with a static member on the enclosing class (rather than in the module scope), thus further encapsulating the details of this solution. The only problem I can see is, what happens when 'A' needs to be thread-safe? IMO, passing around the formal 'outer' object is the way to go. class Foo{ class Bar{ Foo outer; this(Foo outer){ this.outer = outer; } } Bar aBar; this(){ aBar = new Bar(this); } } ..Which is really nothing special, but at least it works. :) All this aside, I don't think inner classes will be coming to D anytime soon, simply because they're almost not even needed. Take Java for example: 99.9% of the time, your inner class declarations are adaptors passed to satisfy some sort of command or event pattern. D's delegates (for which adaptors are the closest thing in Java) already handle this problem much more elegantly, and succinctly. Plus, when declared as an encolsure, delegates already adopt the parent's scope much like an inner class would. Also, one only needs to into consideration the design consequences of true inner classes to realize the major pitfalls. If you look hard at any given inner class, the high-degree of coupling between the inner and outer spaces should leap out at you as a stumbling block for maintenance. Delegates offer some of the same issues, but impose an atomic solution (representing an edge-case rather than a generalized solution, AOP vs OOP if you will) on the developer which helps keep coupling to a minimum. Now Nested Classes on the other hand let you do some nifty things as well: class MyNamespace{ class Foo{ int a; this(int a){ this.a = a; } void Print(){ printf("a = %d\n",this.a); } } } void main(){ MyNamespace.Foo foo = new MyNamespace.Foo(42); foo.Print(); } ::grin::
Jun 04 2004
parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
"EricAnderton at yahoo dot com" <EricAnderton_member pathlink.com> wrote in
message news:c9q2jr$q53$1 digitaldaemon.com...
 In article <c9ns26$hdl$1 digitaldaemon.com>, Ivan Senji says...
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.
Hrm.. never would have thought to do that myself, but if it works! :) I
wonder
 if there's a way that templates or mixins could be used to make such a
design
 less tedious to maintain?

 Just a suggestion: You could also do the same with a static member on the
 enclosing class (rather than in the module scope), thus further
encapsulating
 the details of this solution.
Good sugestion!
 The only problem I can see is, what happens when 'A' needs to be
thread-safe?
 IMO, passing around the formal 'outer' object is the way to go.
Well this is the way i did it at first but changed it so it would use less memory. I have some rellativelly small classes it 4bytes for a reference are too much. I'm thinking how to make it be thread-safe.
 class Foo{
 class Bar{
 Foo outer;
 this(Foo outer){
 this.outer = outer;
 }
 }
 Bar aBar;

 this(){
 aBar = new Bar(this);
 }
 }

 ..Which is really nothing special, but at least it works. :)

 All this aside, I don't think inner classes will be coming to D anytime
soon,
 simply because they're almost not even needed.

 Take Java for example: 99.9% of the time, your inner class declarations
are
 adaptors passed to satisfy some sort of command or event pattern.  D's
delegates
 (for which adaptors are the closest thing in Java) already handle this
problem
 much more elegantly, and succinctly.  Plus, when declared as an encolsure,
 delegates already adopt the parent's scope much like an inner class would.

 Also, one only needs to into consideration the design consequences of true
inner
 classes to realize the major pitfalls.  If you look hard at any given
inner
 class, the high-degree of coupling between the inner and outer spaces
should
 leap out at you as a stumbling block for maintenance.  Delegates offer
some of
 the same issues, but impose an atomic solution (representing an edge-case
rather
 than a generalized solution, AOP vs OOP if you will) on the developer
which
 helps keep coupling to a minimum.


 Now Nested Classes on the other hand let you do some nifty things as well:
I agree they are very usefull.
 class MyNamespace{
 class Foo{
 int a;
 this(int a){ this.a = a; }
 void Print(){ printf("a = %d\n",this.a); }
 }
 }

 void main(){
 MyNamespace.Foo foo = new MyNamespace.Foo(42);
 foo.Print();
 }

 ::grin::
Jun 04 2004
prev sibling parent Kevin Bealer <Kevin_member pathlink.com> writes:
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
Jun 03 2004
prev sibling parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
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.
Jun 03 2004
prev sibling parent Ant <Ant_member pathlink.com> writes:
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
Jun 03 2004