June 04, 2004 Re: Super-private private | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ivan Senji | 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:: |
June 04, 2004 Re: Super-private private | ||||
---|---|---|---|---|
| ||||
Posted in reply to EricAnderton at yahoo dot com | "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:: > > |
Copyright © 1999-2021 by the D Language Foundation