jastrachan | 8 Apr 11:35 2005

Re: Eunumeration Type

On 8 Apr 2005, at 10:18, Russel Winder wrote:

> On Fri, 2005-04-08 at 10:07 +0100, jastrachan@... wrote:
>>> Given that enums are a part of Java 5.0 it would make sense to 
>>> present
>>> enums in Groovy with as little extra syntax as possible.
>> Agreed. Though there's no reason why we can't also add a few extra bit
>> of semantics (e.g. enums knowing how to increment/decrement).
> Is enum arithmetic modulo arithmetic or saturation arithmetic?
>> def summer = june..august
> Aha back to the good old days of Algol68 and Pascal :-)

Yeah! :) Though the one thing that used to irritate the hell out of me 
was in pascal you could never just print out the value of an enum.


def var = june + 1
println "month now $var"

// should print 'july'

>>> Is Groovy a JDK 1.4 based system or is it a Java based system?
>> I'd say Java based, with 1.4 as the baseline.
> So this means replicating lumps of 5.0, 6.0, 7.0 implementation in
> Groovy until all the 1.4 installations have upgraded and then ripping 
> it
> out in favour of relying on 5.0 features.

Kinda yes; I'm hoping ASM does most of the work for us :) Generics are 
not gonna be fun (I'd be happy to leave them out, i'm not much of a fan 
of them anyway - they add lots of verbosity for little real benefit). 
Annotations shouldn't be too hard I don't think to do a 1.4 / 5.0 
version. Enums really are just regular Java classes; so no real big 
deal there AFAIK. (i.e. we can consider macros to just be an AST level 
macro to spit out regular groovy classes).

>> Yeah. I don't wanna depend on 5.0 yet.
> Clearly that is a very reasonable stance in the short and possibly
> medium term but any enum stuff that does get into Groovy has to be
> treated as a short term "hack" pending a shift to 5.0 dependence.

 From what I've seen of enums, they are just regular classes.

>> For enums I think we can just generate Java 1.4 compliant bytecode.
>> Though we should be careful we emit Java 5 bytecode for enums &
>> annotations etc
> I guess this ia all part of the generics / annotations / ASM 2.0
> strategy.  Now that the JSR parser is the default parser I'll have
> another look at a move to ASM 2.0.  This will then allow the 
> possibility
> of doing different code generation for 1.4 hosted systems and 5.0 
> hosted
> systems -- if we want to do that.


>> Agreed. I hope there's no major bytecode changes in 6/7 like
>> annotations/enums/generics... :)
> As far as I know there were no actual bytecode changes in 5.0.  All 
> that
> changed in the JVM was having an extra constant pool entry type.
> Everything about annotations / enums / generics etc. is compiler
> constructed on the 1.4 JVM + extra constant pool entry.

Really? I hope so. I thought 5.0 was not backwards compatible; maybe 
thats just the constant pool entry type?

ASM 2.0 does annotations right? Does that work on 1.4?