[antlr-interest] adding enum token types output for java target

[Terence Parr]

Yikes.I forgot about that whole "can't extend enum" thing. This could  
cause trouble for imported grammars.

I guess only ANTLR knows what tokens should go in there though; if you  
use tokens { IMAG; } it will add IMAG to the enumeration for you.

Oh crap. You're right. how can we have a generic match() method that  
compares token types?

Ter

On May 26, 2008, at 2:09 PM, Gavin Lambert wrote:

> At 08:46 27/05/2008, Johannes Luber wrote:
> >enum is 1.5. It would be nice, if you could still add that to the
> >templates within comments, so targets with a support for enums can
> >simply change the output.
>
> You could also make it an option, or an alternate target (like  
> CSharp2).  Provided that Java supports nested classes (and I think  
> it does), it's possible to build an enum-like class in the absence  
> of explicit enum support.  (I did that in C++ once because I wanted  
> the values to be scoped to the "enum" instead of floating in the  
> parent class or global namespace.)  So the target code needn't  
> change between the two.
>
> The trouble with enums is that they're not extensible; you can't  
> inherit from one and simply add a few extra values (which would be  
> useful for adding imaginary tokens at the parser/treeparser level).   
> And since they can't be a base class the library code will still  
> have to work with raw ints, which means a lot more casts will be  
> required to type-juggle.  It gets messy very quickly.
>
> You could get around this by using an enum-like-class for all  
> targets (so you can have a common base in the library which the  
> grammars inherit from), but then you have to create factory methods  
> and possibly re-implement some of the reflection-like calls (since  
> you won't be able to use the standard enum ones).  I'm not sure it's  
> worth it.
>