Re: [SPAM] [PATCH] Round the Java rough edges

[Joel E. Denny]

On Thu, 8 Mar 2007, Paolo Bonzini wrote:

> > 1. Always define a YYLexer class.
> 
> Always define a public Lexer interface.

Is it possible for the user to add methods to it?  Otherwise, the only 
YYLexer methods available in the parser semantic actions are the inherited 
Lexer methods provided by Bison, right?

> > 2. Provide "%code lexer" to add code to YYLexer.
> 
> If "%code lexer" is given, define a YYLexer class that includes the content
> of "%code lexer".

Bison provides no code for this class except that it forces it to be final 
private, right?  If the user has to write the enitre class himself, why 
should Bison even bother defining it at all?  Wouldn't it be simpler if 
the user always provides this class separately (in the epilogue or a 
separate file)?  Wouldn't "%code lexer" be more useful for the parent 
Lexer?

Maybe you're doing this just to have a way to define the second parser 
class constructor automatically.  If that's necessary (but it's so easy to 
define, I figured the user could do it instead), perhaps a "%define 
lexer_class" that specifies the user's Lexer subclass name would be a more 
flexible approach.

It still would seem simpler to me if the user could work completely within 
the Lexer parent just as he does for the parser class.  That is, he would 
only subtype Lexer (and possibly make Lexer an interface) if a Lexer 
hierarchy actually made sense for his application.

By the way, I just noticed there's a Lexer instance called yylex.  I think 
most of us are used to that being a function.  How about yylexer?

> > 4. Provide "%define parser_class_modifiers" and "%define 
> > lexer_class_modifiers" to specify abstract, interface, final, or other 
> > modifiers on these classes.  Contains just public by default?

> For the parser, I'm still using "%define public" and "%define abstract"

What about final?  

> because I don't like the long name "%define parser_class_modifiers", but
> I'm open to suggestions for a better name.

We butt heads on the long name issue a lot.  :)  I prefer the longer name, 
but it could be abbreviated.

> Ok to commit?

Fine by me.  From what I've seen, I think it's an improvement, but I don't 
have time to review the code in detail right now.