groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: The long path to a new MOP
Date Sun, 07 Aug 2016 19:03:21 GMT
On 07.08.2016 19:37, Jesper Steen Møller wrote:
> Hi all,
>> On 7. aug. 2016, at 13.49, Jochen Theodorou <> wrote:
>> Since this will take several normal releases I think just using a branch will not
do here. Because keeping them just in sync will probably take up most of the time I would
normally use to implement this. So I was wondering... would you guys ok with me introducing
classes marked as "experimental" on the normal branch?
> I have an alternative idea: Wouldn’t it make sense to split the work instead, if somebody
was willing to do the recurring merges with master?

just to show you the impact a bit:

compiler: I may introduce a temporary annotation that let´s the groovy 
compiler use different default classes (GroovyObject, Closure and Range) 
than before. This will require changes in the compiler to make it 
possible and eliminate all the places that implicitly assume a certain 
class for these (GroovyObject mostly here).

runtime/MOP: introducing new parallel standard classes means requiring 
new conversion ways between them. Plus of course the MOP implementation 

Of course there would be still many places that will stay the same and 
are easy to port. but the divergences in the internals will become more 
and more.

>> I was thinking initially about adding a new source folder where these classes go
and let us then omit them during release. But I think this will not work. There will be circular
references. There have to if the new MOPs are supposed to work together somehow. So I guess
it would be just the normal src folder then?
> That would give more room for experiments, and not leak experimental code into releases,
and I’m thinking merging wouldn’t require intimate knowledge of the old and new MOPs.

How to deal with cyclic references?

bye Jochen

View raw message