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.