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
  • GEP-31 Jochen Theodorou

Reply via email to