Confused about Inner Classes

[Jarrett Billingsley]

"Janice Caron" <caron800 at googlemail.com> wrote in message 
news:mailman.494.1193001500.16939.digitalmars-d at puremagic.com...
> Just trying to get my head around inner classes (a new concept for me).
>
> OK, so inner classes get a hidden "context pointer" to the enclosing
> instance. So far so good. But how does that interoperate with
> inheritance. For example:
>
> class Outer
> {
>
>    class InnerA
>    {
>    }
>
>    class InnerB : InnerA
>    {
>    }
> }
>
> Is it the case that InnerB has both a super class (InnerA) and an
> outer class (Outer), and, further, that it's super class has an outer
> class (also Outer)? So an instance of InnerB can refer to "outer",
> "super" and "super.outer" (where "outer" and "super.outer" are the
> same thing?)

Instances of InnerB are instances of InnerA.  Just like in normal 
inheritance, InnerB inherits InnerA's 'outer' member.  Since it's all 
handled by the compiler, I'd imagine it's smart enough not to redeclare a 
new 'outer' member in InnerB.

> Let's get even more bizarre:
>
> class OuterA
> {
>    class Inner A
>    {
>    }
> }
>
> class VeryConfused : OuterA.InnerA
> {
> }
>
> I'm not sure that even makes sense. It's very hard to wrap my head
> around. Is that nonsense?

AFAIR that won't compile.  Inner classes can only be extended by other 
non-static inner classes in the same outer class.  Other uses would be very 
tricky to implement and probably be useless.

> What are inner classes good for anyway?

Things.  ;)

I've run into uses for them with about as much frequency as uses for inner 
functions (which, in my coding style, is to say "fairly often").  They're 
useful when you need to model an "owner-owned" relationship.  Class literals 
(a form of nested classes) can also come up when doing some clever things.