Purpose of MetaClass.getClassNode

[Tatai Márton <ta...@gmail.com>]

Hello,

I was going through the source code of the GROOVY_2_5_X branch, just
studying the inner workings of the runtime. (So if I'm saying something
foolish please excuse my inexperience)
I came across groovy.lang.MetaClass.getClassNode, which strikes me as an
inappropriate method as a part of the runtime. This method seems
potentially useful, but unnecessarily couples compile time to the runtime
apparatus.
As far as static analysis goes, I've found getClassNode used in some tests
for AstBuilder, and as part of some clever tricks in groovy.sql.DataSet.
As I've already established, I'm not an expert at the matter, but I think
the MetaClass interface would be cleaner without this method. I realise
that it's part of a public(?) interface, so deletion might not be an
option, but do you think a deprecation and a stern warning would be
appropriate? The MetaClassImpl implementation of this method only works as
long as the source is available and can be located on the classpath. Even
if this is the case, the compiler is pretty convoluted, and I'm not even
sure that the same AST can be generated at runtime as compile time.
I've tried to look into the history of this method, and a pretty ancient
commit mentions this as a residual feature, which should be removed:
https://github.com/apache/groovy/commit/9ebea0cbddcad1ab6636da61962a368138828bf0#diff-3a2f96e7344aaac477f01c5f7e0d3d88R115

Best regards
Marton

Re: Purpose of MetaClass.getClassNode

[Jochen Theodorou <bl...@gmx.org>]

On 16.04.2017 16:41, Tatai M�rton wrote:
[...]
> I came across groovy.lang.MetaClass.getClassNode, which strikes me as an
> inappropriate method as a part of the runtime. This method seems
> potentially useful, but unnecessarily couples compile time to the
> runtime apparatus.

I also think we have to remove it. Problem is, that the last time I 
think I asked before 1.0 and back then it was used much more often. And 
since we did not want to make breaking changes in this area we got the 
burden of it since then. 3.0 (master should be 3.0) is the next chance 
to get rid of this, thus, yes, any pull request for this is welcome.

> The MetaClassImpl implementation of this method only
> works as long as the source is available and can be located on the
> classpath.

yes, this was from even before transforms, basically your only chance to 
do something like getting an AST similar to what C# offers for example. 
AST transform reduced the need for this kind of logic a lot... still 
would be interesting in cases, by well. Still we do not have a solution 
for that, that works without static information across call sites.

On the other hand... now that I think of it.... There is actually a 
solution with transforms... hmm... well, I do not want to redirect the 
purpose of this thread

> Even if this is the case, the compiler is pretty convoluted,
> and I'm not even sure that the same AST can be generated at runtime as
> compile time.

Define "same AST". Then we talk about if it is possible.

> I've tried to look into the history of this method, and a pretty ancient
> commit mentions this as a residual feature, which should be removed:
> https://github.com/apache/groovy/commit/9ebea0cbddcad1ab6636da61962a368138828bf0#diff-3a2f96e7344aaac477f01c5f7e0d3d88R115

yepp...let�s get rid of it

bye Jochen