Re: [RFA] Java skeleton

[Joel E. Denny]

On Tue, 27 Feb 2007, Paolo Bonzini wrote:

> I find it hard to think of one more function that would be added and not be
> under the control of a % directive.

I can't think of one either at the moment.  It's hard to predict the 
future.  But never say never.

> > But if the Bison user defines his own class to wrap the parser class (like
> > the parser driver), he can create whatever interface he likes for the parser
> > user.
> 
> I think if we can live without the parser driver, it is better

If the user doesn't like the yy member names and doesn't like a parser 
driver, he can always add his own wrapper methods directly to the parser 
class.  There could even be a %define variable (yy_member_access?) that 
moves all yy members to protected or private so that the user has nearly 
complete control over the public interface.  (I was thinking the prefix 
yy_ would be used for members that are not public, that are undocumented, 
that are free to change, and thus that the user shouldn't access.)

By the way, it'll be easier to figure out what the public interface is 
(which is especially necessary if you don't use a yy prefix) if you 
reorganize the parser class so that all public members are first.  I also 
like to see public constructors as the first public members.

> (and the fact
> that Java uses only virtual methods makes me believe this is the case).

I thought final methods and classes were supposed to avoid dynamic lookup.

> I
> don't know of other parser generators for Java that require a parser driver.

I wouldn't know.

Whatever you choose, I'd really like to see it be self-consistent.  I see 
little reason to mimic the C++ skeletons in naming YYACCEPT, YYABORT, 
YYERROR, or YYFAIL.  I imagine Akim's goal was to make C++ semantic 
actions look similar to those in C.  In your case, your chances of that 
are blown already since you define these as constants not methods.  Might 
as well aim at self-consistency within the Java skeleton instead.