Re: [PATCH] Round the Java rough edges

[Joel E. Denny]

On Mon, 12 Mar 2007, Paolo Bonzini wrote:

> > If a method is actually invoked anywhere but the user forgets to declare 
> > it in Lexer, it will be a compile error anyway, right?  This is similar to 
> > when the user forgets yylex or yyerror in Yacc parsers.
> 
> With the nice IDEs Java programmers use, however, I prefer to give a
> nice error message in the user's lexer code, rather than in the Bison
> generated code.

Ok.

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

> > It's supposed to avoid dynamic lookup and thus improve performance, which 
> > is usually important for parsers.
> 
> Final methods can also avoid dynamic lookup cost and can be inlined.

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.