Re: [PATCH] Round the Java rough edges

[Paolo Bonzini]

>>> I believe that would keep things simple and consistent.  
>>> Moreover, the parser class could use lexer_type_name as the type of its 
>>> Lexer member (to avoid downcasts) and of the Lexer argument in the parser 
>>> class constructor.  If the user wanted to make his Lexer subtype an 
>>> interface or abstract class or final or whatever, that would be totally up 
>>> to him because he would define the type entirely.
>>> Now, if you wanted to guarantee that the user defined his lexer type to 
>>> extend/implement the Lexer interface, Bison could add something like this 
>>> to the parser class constructor:
>>>
>>>   Lexer lexer_interface = lexer_arg;
>>>
>>> Type compatibility here is checked statically at least by gcj.  Maybe 
>>> there's a better way to check this.
>> Yes, that would be good.
> 
> Sorry, what's "that"?  Some "better way to check this"?  Or my proposal as 
> stated above?

Your proposal.

> Declaring a class as final is notationally more convenient than declaring 
> all the methods as final.  Moreover, a final class cannot be subclassed, 
> and some users may want such a design.  I realize there are ideological 
> arguments against using final, but is it really Bison's place to force 
> that ideology on users when it's so easy to provide the greater 
> flexibility?  In any case, I suppose this ability could be added to Bison 
> later.

Agreed.

Paolo