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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]