bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: feature tests and %before-header


From: Joel E. Denny
Subject: Re: feature tests and %before-header
Date: Mon, 16 Oct 2006 15:22:08 -0400 (EDT)

On Mon, 16 Oct 2006, Paolo Bonzini wrote:

> > Unlike C/C++, there are no backward compatibility issues for the Java
> > skeleton.  I wonder if you should take the approach of providing one "right"
> > way to do things (the new directives) rather than providing so many
> > synonyms.  What do you think?  It shouldn't be difficult to disable %{...%}
> > and %code-top for all but C/C++, I think.
>
> Yes, you can do that in m4 code.  But I haven't (yet) seen a reason to do
> so.

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?

> Yes, I have.  Usually, packages are used for "bigger" parts of code in Java
> than namespaces in C++, so I'm using name-prefix to change the class name from
> YYParser to something else.

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?

> 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?  
Isn't it considered bad practice (poor encapsulation) not to declare a 
package?

> Besides, supporting %requires or equivalently %code-top or %{...%} is required
> anyway for the imports.

Yes, and I kind of like that %requires would contain nothing but imports.  
This puts a little more potentially useful information in the hands of 
Bison.




reply via email to

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