On 07.08.2016 19:37, Jesper Steen Møller wrote:
Hi all,
On 7. aug. 2016, at 13.49, Jochen Theodorou <blackd...@gmx.org> 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
itself.
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
