Re: feature tests and %before-header

[Paolo Bonzini]

> To improve the readability of Java-based grammars.  In my experience, 
> multiple declarations that do exactly the same thing are distracting and 
> are a sign of a language that's mired in backward compatibility issues.  
> Instead of letting users develop different bad habits, why not start fresh 
> with Java and keep everybody on the same best page?

Well, I had a half-baked idea of making my skeleton compatible with 
BYacc/J, but that would require to make the epilogue a big %code instead 
of a big %requires, which I don't like.

> If the user chooses to put the parser class in a package, it seems useful 
> to let Bison know the name of it.  For example, it's conceivable that 
> Bison might grow a need to generate additional classes in separate java 
> files that depend on the parser class.  I can't think of exactly what 
> those classes would be at the moment, but it seems easy to reserve the 
> possibility.  m4 could easily split:
>
>   %name-prefix="mypkg.mysubpkg.myclass"
>
> into "mypkg.mysubpkg" and "myclass", right?

Well, yes (one caveat is that a name-prefix of "YY" would create a class 
named "YYParser" right now, but that is no big deal).

But if Bison had to create multiple files, it would just copy over the 
%code-top and/or %requires to all the files.  In fact, I'm already 
qualifying all the class names in the skeleton to avoid errors if 
somebody imports a "foo.bar.PrintStream" class; it would be no big deal 
also to do the same in any other generated class.

> > All the code in a Java parser resides in a single
> > Java class or in its inner classes, so it is quite pointless IMO to reserve a
> > whole package for that.
>
> A whole package?  Can't another Java file put classes in the same package?  

Yes, of course, you have a point here.  But OTOH the same holds if the 
package is specified with the Java package keyword in a code block.

> Isn't it considered bad practice (poor encapsulation) not to declare a 
> package?

I'm not suggesting having no package -- but the user should specify it 
manually anyway, no matter if in a code block (%{...%}, %code-top, 
%requires) or as a %name-prefix.  Having one more "mandatory" directive 
(%name-prefix to specify the package) in the grammar file makes things 
more complex than necessary, IMO.

Paolo