On May 18, 2010, at 2:58 PM, Scott Stanchfield wrote:
> There are several advantages to enums:
> * there is a discrete set of values that can be used (no accidental
> 42's passed in when 42 isn't a token type)
> * the enum value can carry extra information
> * the enum values can override methods differently
These are all excellent advantages. I believe that these mostly apply when
you're writing code, not generating. Just like the compiler generates integers
underneath, if antlr is generating integers, it's probably okay.
> OH - one of the things that's clouding this is that you really don't
> need the numeric type identifers anymore. You can just have
>
> public enum TokenType {
> IDENT, INT ...;
> }
>
> then in your match method:
>
> void match(TokenType type) {
> if (LA(1).getType() == type) {
> ...
> }
> }
The only problem is that match() lives up in the superclass in the library but
the generated parser needs to define the enum.
I also have the problem that I need to merge token types from multiple grammars
for grammar imports. This gets more competition with enum types without
inheritance.
>
> And you can use the types in a switch statement:
>
> switch(type) {
> case INT:
> case IDENT:
> ...
> }
>
> No more magic numbers! Woohoo!
ANTLR already uses the labels when possible such as INT. If you use a literal
in your grammar such as ';' in don't label it in the lexer, than I had no
choice but to generate the integer token type or a weird label like TOKEN34.
Ter
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
"il-antlr-interest" group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
