groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesper Steen Møller <jes...@selskabet.org>
Subject Re: Progress on the Antlr4-based parser
Date Mon, 07 Mar 2016 13:16:31 GMT

> On 7. mar. 2016, at 13.52, Jochen Theodorou <blackdrag@gmx.org> 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


Mime
View raw message