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

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