On 09.05.2017 08:38, Cédric Champeau wrote:
I'll let Jochen answer that, I don't recall the reasons why it was a
breaking change. I think part of the answer is that Groovy classes
implement GroovyObject, but I miss the details, I'm no dynamic expert ;)
2017-05-09 8:34 GMT+02:00 Graeme Rocher <[email protected]
<mailto:[email protected]>>:
Would it make sense to have the metaClass field of GroovyObject
initialise lazily? In what circumstance would that be a breaking
change? Concurrency?
I do not remember the details anymore, since I made that experiment
years ago. What I remember is that it broke tests and some kinds of
setting meta class in an initializer block or was it adding meta methods
there? Anyway. I remember trying it, it was not working and I did not
spend much more time on trying to make it work. So a new try could bring
fruit... especially in the context of CompileStatic. Frankly I don´t
think a static compiled Groovy class does really have to implement
GroovyObject at all.
As for the lazy init... it is legal to set the field to null and then
call a method dynamically, since that will reinit the field.
Of course GroovyObjectSupport is something else, since that always does
eager init.
concurrency is in theory an issue, but since getting a "new" meta class
from the registry involves synchronization the worst thing that can
happen is that the registry is asked more than actually needed or that
an old value non-null is still visible in another thread. But I always
said, that this is something we simply leave to the user.
bye Jochen
