On Tue, 17 Oct 2006, Paolo Bonzini wrote:
> 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).
I just took a closer look at the C++ skeletons. This is how you specify
the name of the parser class there:
%define "parser_class_name" "MyParser"
This frees %name-prefix completely for the package.
> But if Bison had to create multiple files, it would just copy over the
> %code-top and/or %requires to all the files.
You seem to be assuming that the other files would necessarily be in the
same package. Maybe that's a valid assumption. If not, Bison would need
to qualify references to the parser class: mypkg.mysubpkg.MyParser.
Obviously, it's a little hard to predict the future here, but it seems
wise to make information available to Bison when possible.
> > 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.
Sorry, I just meant that a package directive would be common. I didn't
mean that Bison should make it mandatory.
