[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 10:07:33 +0100 |
User-agent: |
Thunderbird 1.5.0.10 (Macintosh/20070221) |
>>> 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