Guillaume Laforge | 5 Apr 2008 00:33
Picon
Gravatar

Re: final Groovy JSR?

On Fri, Apr 4, 2008 at 11:59 PM, Bill Shannon <bill.shannon@...> wrote:
> [...]
> > Back on the level of integration mentioned above, and on this
> > portability / interoperability aspect, Groovy mandates a seamless
> > integration with Java. But does it mean we'd also mandate a perfect
> > interoperability with other Groovy implementations?
> >
>
>  I think it would be better if you did, but it's up to you to decide.

Yes, for sure, conceptually speaking, this would be desired.
For Java, this is simpler as a call to a method is directly encoded in
the bytecode.
No intermediary layer of indirection.
It then just depends on the runtime part (JDK classes, third party
libraries, etc)
But for a dynamic language, in the bytecode you'll find some calls to
utility classes handling the double dispatch.
Some of them are public APIs (which will be part of the JSR), but
others may be present that are specific to each implementation.
So we'll have to think deeper as to what we really want to make portable or not.
Tricky issue :-)

> [...]
>  You're allowed to make that choice.  It's up to your expert group to
>  decide whether that's a good choice.  Personally, I think this might
>  be acceptable for a first release, but long term it will limit
>  acceptance of Groovy.  But you should work through the scenarios for
>  how you expect people to use Groovy to see if it will be an issue for
>  you.  For example, do you expect people to write libraries using Groovy,
(Continue reading)


Gmane