Angry citizen stikes once again. forward references problems

[kris]

Derek Parnell wrote:
> On Sun, 30 Jul 2006 18:57:14 -0400, Jarrett Billingsley wrote:
> 
> 
>>"Derek" <derek at psyc.ward> wrote in message 
>>news:zbzgquaqpewl$.brpiyqr0sclz.dlg at 40tude.net...
>>
>>>I don't understand this Dawid. It seems you are trying to use a nested
>>>class inside another class, and I'm sure you can't and shouldn't do that.
>>
>>Why not?  What about a parent "factory" class, which needs to create 
>>instances of a nested class, which the user can use?  The nested class can 
>>still access its outer class, and the user can use the nested class 
>>instances just fine.
>>
>>
>>>I thought the purpose of nested classes was to restrict the scope of the
>>>nested class to its parent and thus trying to use it outside of the parent
>>>doesn't seem right to me.
>>
>>Sometimes that's true.  Sometimes you just want the nested class to have 
>>access to the outer class.  Granted, you can do this with friend classes, 
>>but.. as mentioned above, if you want an "owner/owned" relationship between 
>>the classes, using a nested class seems somewhat more elegant.
> 
> 
> Okay ... but why would you want a nested class to be used as a type inside
> another class? Seems like a silly thing to do. What's the advantage of
> doing that?
> 
> 
>>>D won't let you do even the more simple case ...
>>>
>>>//------- test3.d -----
>>>class X
>>>{
>>> static class NX
>>> {
>>> }
>>>}
>>>
>>>class Y
>>>{
>>>    NX q; // test3.d(10): identifier 'NX' is not defined
>>>}
>>>// -------------------- //
>>>
>>>I think dmd is working correctly, though the error messages are not 
>>>exactly
>>>helpful.
>>
>>Namespaces, namespaces.
>>
>>Class Y
>>{
>>    X.NX q;
>>}
>>
>>And you could even "alias X.NX NX;" if you wanted to.
> 
> 
> Seems wrong to me. I can't see why one would bother making obscure,
> hard-to-maintain, hard-to-read classes definitions using this technique.
> Seems counter-productive.
>  
> 


Aye ... I'm a big fan of Factory designs, and nested-classes, but would 
typically not expose the inner class in that manner ~ would be exposed 
via an interface or something instead.

As I understand it, inner-classes (as a concept) are intended primarily 
as a convenient means of encapsualting specific internal functionality, 
for either handing off to a framework or for simplifying internal 
implementation detail. I can't recall reading /any/ papers or documents 
suggesting they should be made available as general-purpose public 
classes, and don't recall ever finding a need to do so. Of course, 
that's just my experience only.

Would be very interested to understand why it's needed in this case ...