[antlr-interest] Complaints about BaseAST implementation
Akhilesh Mritunjai
virtualaspirin at yahoo.com
Wed Oct 12 13:37:14 PDT 2005
Hi,
One, not two to be precise.
'type' is basic property of *any* AST node that we
want to be processable by ANTLR (parser and
treewalker). I don't think 'text' property belongs
here (AST interface) ... its important in parser, but
has no significance at all in treeparser, for example.
The concrete class I proposed would return these
'bogus' values because these values are not required
everywhere. eg, apart from CommonAST, there are three
more descendants of BaseAST - ParseTree, ParseTreeRule
and ParseTreeToken, and none of the three need either
type or text fields. So this concrete class is just a
convenience class so that one doesn't have to
implement 5 or so methods in ParseTreeRule and
ParseTreeToken with same fuctionality... that apart,
it might not be needed at all if one is comfortable of
putting them in both's common abstract parent
ParseTree.
- Akhilesh
--- Martin Probst <mail at martin-probst.com> wrote:
> Hi,
>
> I agree with you, except this sounds a little
> strange:
>
> > So, either all classes deriving from BaseAST
> should
> > implement get/set child/sibling AND get/set
> text/type,
> > OR a minimal concrete class can be provided that
> > derives from BaseAST (other classes derive from
> this
> > concrete class) and implements node connectivity
> > (right/down) and returns empty string and 0
> > respectively for getText() and getType(). Again,
> > implementing them in BaseAST is incorrect. It is
> an
> > abstract class and *must not* have any say in
> things
> > it has no info about.
>
> Why would you create a _concrete_ class, and then
> have it return bogus
> values on two method calls? Who should instantiate
> that class? I guess
> it should be abstract, don't you think?
>
> Martin
>
>
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
More information about the antlr-interest
mailing list