oops, I just saw that I gave the wrong subject to my mail (I was lazy and 
just replied to not have to type the address...), so I resend it with the
correct subject to attract the right kind of people. Sorry for the mess...


> Playing around in the ParseNode hierarchy (to implement the
> ParseNodeEnumerator posted a few days ago), I noted two odd nodes:
>
> 1. DecompilerConstructor: why is this under ParseNode ? I looked where it
> was used, and got the impression that is never used as a real parse node.
> This would mean that it is best factored out, since this is not very
> clean...
>
> 2. Encoder: it seems that this class is used to store information about
> literals and temporaries during parsing. This is then added to a MethodNode
> (so that the methodNode knows the names and positions of these entities in
> the source). While this is certainly usefull and clean (it serves as a
> 'memory' during parsing), I again have the impression that this class is not
> a real parsenode itself.
>
> So, my question to the Parsing experts: Can these classes be removed from
> the ParseNode hierarchy, and moved somewhere else ? Are they an example of
> implementation inheritance (in which case we could put this in the comment,
> or put them under a common superclass with some descriptive name
> (ParsingHelpers)) ?

--
Roel Wuyts                    Programming Technology Lab
rwuyts at vub.ac.be              Vrije Universiteit Brussel
http://prog.vub.ac.be/~rwuyts
Webmaster of European Smalltalk User Group: www.esug.org