STO and Type class heirarchy

Compiler Experts,


I'm constructing a compiler/translator for a Java-esque OO programming
language and I'd like to know your thoughts on formulating effective
STO (symbol table object) and Type class hierarchies or meshes. As
things now stand, I have a single STO class with a Type member
variable and a whole slew of member functions of the form:


public boolean isClass() { stoType.isClass() }
public String getSuperclass() { stoType.getSuperclass() } /* Returns the
identifier following the "extends" keyword in the class declaration. */


The Type class has been subclassed into the various types encountered
in the source programming language (i.e. NumericType, IntType,
ClassType, StringType). Because the member variable stoType of the
STO class is of the base type Type (as opposed to a subclass of Type
like ClassType), in the Type class I have many functions of the form:


public String getSuperclass() { fatalError("Calling Type.getSuperclass()."); }


The above function produces a fatal error, killing the compiler,
because getSuperclass() should only be called on STOs that have an
stoType that is an instance of ClassType. I've implemented things
this way in order to avoid an excessive reliance upon typecasting.
For example, if I wished to retrieve a _known_ class STO from the
symbol table, I would do the following:


STO classSTO = symtab.access(className);
if (!(classSTO.isClass())) fatalError("The symbol table is messed up.");


I know the following seems much cleaner (assuming symtab.access
returns an STO and the STO class has been subclassed):


ClassSTO classSTO = (ClassSTO) symtab.access(className);


but when I actually tried to subclass the STO class, I found that the
STO inheritance hierarchy would often come into conflict with the Type
inheritance hierarchy, producing a really big mess. Perhaps this is a
result of trying to retrofit things after weeks of using a single STO
class, but I've since gone back to my old way of doing things.


Any suggestions would be appreciated.


Alex

Return to the comp.compilers page.
Search the comp.compilers archives again.