Hi,
forgot to send it from the apache.org account, because my normal account
is not surviving the mailing list transformation properly and then gets
marked as spam. That extends also to for example proton.me mails.
Anyway, the original mail:
On 8/31/26 18:39, Jochen Theodorou wrote:
Hi,
I just progressed on some work that was dangling for a really long time
and results are now in GEP-31
https://github.com/apache/groovy-website/blob/asf-site/site/src/site/
wiki/GEP-31.adoc
This is not an implementation spec, it is not on purpose. It should be
enough to start an implementation and to discuss the general idea. I
think it has a lot of value. This is not really a new MOP or for
performance, this is more a story about protected a runtime or library
from unwanted changes in the meta class universe. One of my long term
goals is still a Groovy implemented 100% in Groovy... at least to make
it possible. Even static compilation in its current state will not make
this possible as extension methods may brake out into unrestricted
scopes. Imagine implementing MetaClassImpl in Groovy and then a DGM
wants to use the metaclass of MetaClassImpl for method dispatch. And now
think this extension method is used to get the target method. GEP-31 can
solve that problem.
```Groovy
@Realm(LIB_X_REALM)
@CompileStatic
class LibX {
...
}
```
with
`LIB_X_REALM = Core extensions + LibX extensions + isolated MetaClass
semantics`
then LibX does not suffer extension method pollution from another LibY
it depends on and just happens to be on the classpath. The static
compiler has a precise set of extension methods to consider, instead of
discovering them through the service approach we have right now, which
is generally open and depends on what I currently have on my compile
classpath. Since the extension methods are known at compile time now,
without a service lookup, the extension methods do not need to be
precompiled or discovered.
```Groovy
class Person {
String name
}
@RealmDef
LIBRARY_REALM = {
extends GROOVY_DYN
metaclass isolated
}
@Realm(LIBRARY_REALM)
class Library {
static void install() {
Person.metaClass.greeting = { "hello $name" }
}
static String run(Person person) {
person.greeting()
}
}
def person = new Person(name: 'Joe')
assert !person.metaClass.respondsTo(person, 'greeting')
use(LIBRARY_REALM) {
Library.install()
assert person.greeting() == 'hello Joe'
}
assert !person.metaClass.respondsTo(person, 'greeting')
```
Could be an interesting story for using meta programming in testing.
I also think this is groundwork for allowing a future new MOP and
especially experimental MOPs in a controlled way, without having to
exhibit it to the user. The realm specifies the MOP. It could be used to
enable a completely different MOP.
I would be interested in thoughts about this.
bye Jochen
