Re: [PATCH] Round the Java rough edges

[Paolo Bonzini]

>> 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?

He can downcast.  But you have a point here.

> Wouldn't "%code lexer" be more useful for the parent Lexer?

It would be if the parent were an abstract class.  Since it is an interface,
it's much less interesting to add things there.

> 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.

Unfortunately, I have to provide a parent for the user lexer class,
in order to make it a compile error if the user forgets a method.

> 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?

Fine by me.

>>> 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?  

I don't think there's a good reason *ever* to use final.  In fact, I'm
going to be coherent and remove it from the "%code lexer" class.

Paolo