5 Apr 2008 00:33
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(Continue reading)> [...] > 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,
> [...]
> 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,
RSS Feed