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

Re: A lot of prduction classes

Hi Mattias.

In the design of SableCC ASTs, one of the important goals was to
simplify the maintenance of a compiler/interpreter over time.

This motivation (and also "consistency") explains the generation of 2
distinct classes for the production & alternative of productions with
single alternatives.

So, for instance, you can later decide to add a new alternative to a
production without having to change existing code.

To understand the problem more clearly: if we were to generate a single
class, which one should it be?
(a) Axxx, or
(b) Pxxx

If we choose (a), then if we later change the "single production", all
other productions referring to this one through a child get/set method
will have to change.  Any user code using these methods will also have
to change the type of variables involved, e.g.:

Axxx v = node.getXxx();


Pxxx v = node.getXxx();

If, instead we choose (b), then this means that some (but not all) Pxxx
classes will now have get/set methods.  As soon as a new alternative is
introduced on such production, the code performing get/set calls will
have to change in a similar way to (a).

Anyway, what is the problem with having more classes?  It certainly is
not "instance size", as this is solely dependent on the number of
non-static fields.  It is not either "method call" time overhead, as
with a high probability, the get/set method will be encoded as "static
call", as Axxx classes are final.

The only problem left is class loading.  The time to load SableCC AST
classes efficiently can be dramatically reduced by creating a .jar file
and putting the whole application into it (specially if classes are
loaded over a network, be it the Internet, or a network file system like

Have fun!

Etienne M. Gagnon, M.Sc.                     e-mail: egagnon@j-meg.com
Author of SableCC:                             http://www.sablecc.org/
and SableVM:                                   http://www.sablevm.org/