These are two very important questions, which surprisingly leads to
that same answer. So I cross post in to Groovy User List as well.

The questions are
- if there is a future possibility of merging Groovy++ into standard Groovy?
- Or of an integration strategy where the Groovy++ jars are
complimentary to the standard Groovy jars instead of replacing them?

Let me start with facts.

Fact number one - Groovy++ is not competitor or replacement of Groovy.
Groovy++ is our way to make Groovy more competitive in the booming
polyglot world (JRuby/Scala/Clojure). There is no intention to replace
Groovy. The intention is to extend areas where it is applicable. The
most important value of Groovy++ are performance critical and highly
concurrent applications and big manageable and refactorable codebases.

Fact number two - Groovy++ binaries should not replace Groovy
binaries. By design (thanks to great architecture of Groovy) you just
need to add G++ jar in to your class path and that's it. We are not
100% here yet. Only 98% :) Two remaining pieces are
- G++ requires not yet released Groovy 1.7.5 because of some bug fixes
done there
- G++ has experimental feature (.gpp file extension where you don't
need to use @Typed at all) which require some support from Groovy core
and we stil did not find yet nice way to integrate it in to the core.
So as of now we need to apply tiny patch for that and have our own
build of 1.7.5. These issue under close investigation and hopefully
will be resolved before 1.7.5 released

Fact number three - there is close cooperation between both projects
in many areas
- both me and Roshan are comitters in Groovy Core.
- Dierk helps us a lot with language design issues by pushing hardly
to keep semantic as close as possible to regular Groovy and advising
on really delicate language matters.
- Graeme's teach and advice on managing community in open-source way.
- Friendly critique by Guillaume and Jochen (even when we are totally
disagree or it looks sometime that we have battle) helps us a lot to
define right line of evolution
- Already now we have serious discussions about possibility of
contributing in to Groovy Core our implementation of traits (most
likely will be part of 1.8.0) and how knows what will be the next.

Fact number four - It is a bit too earlier to think about integrating
Groovy++ in to Groovy Core right now. G++ is still very young project.
It was started less than a year ago as experiment. Obviously we did
long way since that time - we have working compiler, interesting
library, Grails integration, lightweight Gretty framework and slowly
start gaining some popularity. Another obvious thing is that we still
need more freedom to experiment with language features than possible
in already widely used Groovy Core. My personal belief is that Groovy
2.0 design time (we expect a lot of breaking changes at that moment
anyway) will be exactly very right time to consider such integration.
I am sure at that moment we will have stable and widely used Groovy++
1.x out. What would help a lot in mean time if Groovy++ would be seen
as friend and equal member of Groovy eco-system and not as competitor.

Fact number five (philosophical one so controversial) - you can not
copy/paste code between statically and dynamically typed parts without
being careful. The problem here is not only because G++ allows you a
bit richer syntax (mixed mode, less need for 'as' keyword, traits,
[]/[:]-syntax for constructors - theoretically all these features are
supportable in dynamic groovy at least to some extent) The real
problem is just very different nature of static and dynamic dispatch.
Rough analogy can be C/C++ compile-time define which can totally
change behavior of your code. Some people believe that it can lead to
confusion of not enough experienced users. I personally don't share
these concern and think that professionals know very well how to deal
with such problems.

My conclusions are the following
- Groovy++ is friendly younger brother of Groovy and the projects are
influenced in both directions
- There is definitely possibility of merging Groovy++ in to Groovy
Core in the future. I think most logical time to consider such merge
will be Groovy 2.0 design time
- The integration strategy where the Groovy++ jars are complimentary
to the standard Groovy jars instead of replacing them are exactly by
design and coming in to reality very soon.

I would really appreciate comments/opinions of other developers of
Groovy Core on that line of reasoning. Guillaume, Roshan, Jochen,
Dierk, Graeme, Paul, Anders, Peter, please-please-please share your
thoughts. Sorry if I forgot someone.

Best regards
Alex

On Fri, Sep 3, 2010 at 3:31 AM, Ben <benlperkins@(protected):
> First off I'd just like to say how happy I was to learn about the
> Groovy++ project.  I enjoy Groovy syntax but there are definitely
> times where I'd prefer to have the greater performance and compiler-
> sanity of static typing.  Thanks for all the work you're putting into
> it.
>
> I'm curious if there is a future possibility of merging Groovy++ into
> standard Groovy?  Or of an integration strategy where the Groovy++
> jars are complimentary to the standard Groovy jars instead of
> replacing them?
>
> Thanks!
> Ben

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email