Hi all,
when looking at https://github.com/apache/groovy/pull/2710 I was
thinking that something is going wrong here on a conceptual level.
we have quite a few cases to consider here, but in general (in no order
really):
(1) we do not want to call invokeMethod, getProperty or setProperty
directly if we can avoid it
(2) for dynamic Groovy this implies caching using invokedynamic and
getting the information from the meta class now
(3) GeneratedClosure allows a simplified path since we know there is no
custom MOP logic for these with default MetaClass
(4) call is supposed to be used to call doCall only
(5) providing custom call methods is actually not intended
(6) static compilation needs to call doCall directly
(7) static compilation needs to can't go through getProperty or setProperty
(8) a Closure may define multiple doCall methods.
What I mean with 4+5.
If you define subclass Closure and provide a call(String) method and you
do a call like cl("foo") (cl is the instance of the custom Closure),
then this call is supposed to fail. There is no doCall method at all.
If you subclass Closure and provide a doCall(int) method then cl(1) is
supposed to work, but cl("foo") still fails since there is no doCall
method fitting that argument.
Which leads to (6)
The big problem for static compilation is that it this doCall method
might be hidden if we just provide Closure<T> as type. And that means
static compilation may have to fall back to dynamic invocation for that
- or go through call, which does a kind of dynamic invocation. So number
(6) (and probably 7) can currently actually not be realized.
Now we added PackedClosure, which is very similar to GeneratedClosure,
except that there is no doCall method and the method is instead in the
host class, plus there is currently only one doCall analog possible plus
nothing in the PackedClosure may escape the Closure. Also, PackedClosure
replaces GeneratedClosure in some cases, without being a
GeneratedClosure, so the MOP behaviour is different for the two - which
could lead to problems. And again here the call-path seems to be the
only way to invoke the real method. Strictly seen PackedClosure requires
its own logic in MetaClass. And unlike GeneratedClosure, all
PackedClosure have only 1 MetaClass, which they share
But it is not only static compilation and the usage of PackedClosure
that have trouble with this architecture it is also invocation through
Java, especially our GDK.
Before making any suggestions about improvements - does somebody
disagree with this?
bye Jochen
