[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Round the Java rough edges
From: |
Paolo Bonzini |
Subject: |
Re: [PATCH] Round the Java rough edges |
Date: |
Mon, 12 Mar 2007 08:41:20 +0100 |
User-agent: |
Thunderbird 1.5.0.10 (Macintosh/20070221) |
> 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.
> 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.
> 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.
Paolo