inner member classes in final outer class

[coxalan]

Hello,

thanks for all the answers on this topic. Now I understand that with the current implementation of inner member classes, it is _not_ possible to drop the context pointer for final outer classes.

Regan Heath Wrote:
> Should static outer references be the default behaviour?  It seems to be 
> a neat little optimisation, assuming it doesn't cause destruction 
> problems as described above and maybe even then.
> 
> The only case I can imagine wanting a seperate outer reference for each 
> inner class is when I need to move inner classes from one outer to 
> another, eg
> 
> auto o = new Outer;
> auto p = new Outer;
> auto i = new o.Inner;
> i.outer = p;
> 
> I'm not sure this is even possible currently and I can't think of a 
> reason why you might want to do this.
> 
> Regan

This is quite similar to my feelings about member classes:

Consider again:

class Outer {
    class Inner {
    }
}

main() {
    Outer o = new Outer;
    o.Inner i = o.new Inner;
    

    Outer o2 = new Outer;
    o2.Inner i2 = o2.new Inner;
}

In my dream world the preferable behaviour of inner member classes would be like this:

Then the type of 'i' should be 'o.Inner'. That would imply that the reference pointer to 'o' is part of the type, and thus there is no need to store is. Furthermore, 'o.Inner' and 'o2.Inner' would be different types and thus, they could have different static class members.

But the real behaviour is this:
Although I write 'o.Inner' above, I could have written 'Outer.Inner' as well, and really the type of 'i' is 'Outer.Inner' and not 'o.Inner'. That means that the context pointer cannot be dropped (because for example I could do i2=i), and that 'o.Inner' and 'o2.Inner' have the same static namespace.

Like Regan i wonder if there are cases where the 2nd behaviour is the better one, and if yes, what such a case looks like.


I know that the first variant which I would like to see raises some issues:
* 'o' probably should be final.
* The problem addressed by Kirk McDonald: 'o.Inner' objects could have a longer lifetime than the outer Object 'o'. This could be solved in two ways: Firstly, the garbage collector does not delete 'o' as long as 'o.Inner' objects exist. Secondly, allow 'o.Inner' objects only within the scope of 'o'.
* The main problem: The symbol 'o' only exists within its scope. So the type 'o.Inner' only exists within the scope of 'o'.

coxalan