dcsimg
Suggested API Change
1 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   Dave_Herman
Posted On:   Tuesday, May 15, 2001 01:33 PM

Hello, I posted this on comp.compilers.tools.pccts and it didn't generate any response, so I thought I'd give it a try here, since so far I've gotten great responses here. My suggestion It's a small point, really, but I was noticing that the AST interface and the default CommonAST class specify the getFirstChild , getNextSibling , etc. methods as public . My suggestion is to make these methods protected . Why I would like it What I'm doing with the API, and what I imagine isn't too uncommon, is extending the default AST classes with my own hierar   More>>


Hello,




I posted this on comp.compilers.tools.pccts and it didn't generate any response, so I thought I'd give it a try here, since so far I've gotten great responses here.




My suggestion




It's a small point, really, but I was noticing that the AST interface and the default CommonAST class specify the getFirstChild ,
getNextSibling , etc. methods as public . My suggestion is to make these methods protected .




Why I would like it




What I'm doing with the API, and what I imagine isn't too uncommon, is
extending the default AST classes with my own hierarchy of AST nodes,
and I want to hide the getFirstChild and getNextSibling kinds of
methods with more specific methods tailored to my particular abstract
syntax, in order to encapsulate the underlying structure of the tree.
Here's a simplified example:



			// SYNTAX: for var a := 1 to 10 do ... end
			
public class ForLoop {
...
public Variable getIndexVariable() {
return (Variable)getFirstChild();
}
public Expression getLowerBound() {
return (Expression)getIndexVariable().getNextSibling();
}
public Expression getUpperBound() {
return (Expression)getLowerBound().getNextSibling();
}
public Statement getBody() {
return (Statement)getUpperBound().getNextSibling();
} ...
}



In this case, I don't want the rest of the program to know about the
order of the nodes, and they shouldn't deal with casting, etc, so it
should only expose those public methods I listed, but not getFirstChild
or getNextSibling .




Why it's not as drastic a change as it seems




If a superclass defines a method as protected , a subclass can redefine that method as public . The reverse is not true, however: if the superclass defines a method as public , the subclass cannot redefine it as protected
(the reason being, I believe, that you would be able to circumvent the
change by recasting an object of the subclass's type as the superclass to call the method).




So it doesn't hurt anyone to make the base class protected , since you can always define your subclass's implementation of these methods as public , and nothing's changed. But with the base class defining the methods as public , they must remain public in all subclasses.




Why it might in fact be drastic




The major problem with this, however, is that interfaces can't define
protected methods. So antlr.AST would have to be turned into an abstract
class in order to achieve this. Obviously this means implementors are a little more restricted, i.e., they have to inherit from AST or one of its subclasses. I'm not sure what the ramifications of this would be, but I imagine it could be the sticking point.




Other possible solutions




An annoying solution would be to create wrapper classes for all of the
AST node classes, and have the rest of the program access the AST only
through these classes. But that would be pretty ugly and certainly no
fun to write. :)




Is this reasonable? Are there other solutions I haven't thought of?




TIA,

Dave

   <<Less

Re: Suggested API Change

Posted By:   Terence_Parr  
Posted On:   Tuesday, May 15, 2001 07:43 PM

Hi Dave. Quick comment for I take off on a week's vacation. I like what you are suggesting for a few reasons, but the mechanics of this stuff in Java makes it cumbersome. Can you try something with another kind of interface? Wait that won't work.



Similarly, I would like to make ANTLR ASTs compatible (i.e., implement) DOM nodes. The problem is that their methods and mine overlap, which is "perfect" minus the return type mismatch of DOM vs AST!!!! Damn! Without breaking backward compatibility or doing a wrapper, we cannot parse DOM trees with a grammar. Argh. Thoughts anyone?
About | Sitemap | Contact