> On 7. mar. 2016, at 13.52, Jochen Theodorou <[email protected]> wrote:
>
> hehe... outer.super() give me a real WTF moment here ;) I have no idea what
> it does... even fantasy fails miserably here. It is actually more important
> to keep the grammar maintainable, then to add every obscure feature Java has
> to offer.
It’s really not too strange, compared to e.g. lambda method escape analysis ;-)
Each (nonstatic) inner class instance has an implicit reference to its
enclosing (outer) instance, which it will get automatically if produced by a
method of the outer instance. However, if you construct an inner class from
somewhere else, you need to specify which outer instance it belongs to. That’s
why we have “placement new”.
If you make a static inner subclass of the non-static inner class, the
constructor must specify the outer instance. That’s why we need the outer super
placement syntax. In effect:
C(A outer) {
outer.super();
}
translates into something like:
C(A outer) {
B.<init>(outer);
}
But I agree: Enough already! :-)
>
>>>> * ./benchmark/bench/heapsort.groovy uses access modfiers on the
>>>> script’s local variables — that’s not really allowed, is it? How
>>>> should that work? It can’t get it to work in Groovy 2.4.x
>>>
>>> You mean like "public static final long IM = 139968"? It does not
>>> really make a semantic sense to allow this. For convenient copy&paste
>>> this could be allowed... if it poses no problem, I think it would be
>>> nice to have. But it is not really required
>>>
>> But what should it mean? Should it become fields in the Script class, or
>> just be stripped of access and staticness and introduced as locals in
>> the main() ?
>
> yes
>
So - “Yes” to which side of the disjunction? Member or local?
>
>> Since it doesn’t work in Groovy now, I don’t understand why it’s in the
>> repo at all…
>
> I think this used to work before... which probably is why. If I would find
> now out why we do not allow it anymore…. on the other hand this is a strong
> indicator of not needing it as well... so ditch them ;) But "final" you will
> need.
It’s not a big issue, it’s just a matter of deciding which one, and perhaps
updating the docs, which seem to forbid this.
Final is covered.
-Jesper
