[antlr-interest] Complaints about BaseAST implementation

[Akhilesh Mritunjai]

Hi Andy

--- Andy Tripp <atripp at jazillian.com> wrote:
> All ranting aside, I don't see how BaseAST can
> implement AST
> and thus provide methods like getFirstChild() and
> getNextSibling() without
> having any fields. Can you say specifically how that
> can be done?

It doesn't have to! Thats what my point is.
BaseAST is abstract, so there is no obligation on it
to implement anything it has no idea about. It is the
duty of concrete class inheriting from it to provide
concrete implementations of set/getFirstChild() and
set/getFirstSibling() etc. How the concrete class
implements them is again of no concern of BaseAST. The
contract from AST interface says they return an
instance of type AST... so as long as it is fulfilled
by concrete class everything should be fine.

> But BaseAST itself implements the tree
> relationships, not
> your subclass.

Thats what is wrong. BaseAST should not do it. It
implements just the algorithms, which should have
nothing to do with how data is *actually* stored.

> If you want to do that yourself, you
> shouldn't
> be subclassing BaseAST.

But there is problem with it. BaseAST implements a ton
of algorithms which work just fine. They are tested
and would work (may not be most optimally) whatever
way data is stored. I don't want to reimplement (and
debug) them again... I don't even want to copy/paste
them in MyBaseAST (which will be *identical* to
BaseAST with the two fields less).

So eg, addChild() would work fine even if childs are
stored in a doubly linked list, however, if the
implementer wants better performance she/he might
choose to implement it in fashion that gives O(1) 
performance rather than O(n) which is right now.
Again, it is implementer's choice.

- Akhilesh



		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/