2009/11/22 Nicolas Cellier <[email protected]>:
> Without looking at RB code, this is how I would handle it:
> 1) Reify Smalltalk tokens, and create a SpaceToken (can include
> various separators character and comments)
>  the tokens just include a copy of corresponding source text.

As far as I know this is what Gwenael did.

> 2) Scanner creates a linked list of tokens including SpaceTokens

This approach works very well for instance variable or class renames,
because a single identifier token is replace with a different one.

Most refactorings however replace complex node trees being generated
from code, coming from a rewrite expression or another method. This
typically involves several nested replacements, inserting/removing
parenthesis, inserting/removing statement separators,
wrapping/unwrapping into blocks, changing indention, etc. Furthermore
the code needs to decide if the space/comments between two adjacent
nodes belong to the node before or after the tokens.

> 3) Parser parses the stream of tokens and build an AST that retain
> pointers to the links (firstLink and lastLink)
>  The advantage of storing links rather than position is that we can
> add/remove links easily without recomputing positions

Yes, but at the same time the engine has to ensure that all the
transformations are performed correctly. As soon as you have to keep
the two data-structures (the token-list and the AST) in sync, this
becomes highly non-trivial for anything more complex than a simple
rename.

> 4) refactoring operates on AST and replaces links content,
>  eventually if it add or remove links, then some special care of
> intersticial SpaceToken has to happen.
> 5) printing refactored source code is printing the tokens verbatim
> (that is just nextPutAll: their contents)

The current code does a much more conservative approach, that is very
simple and ensures correctness at each step. Whenever a node is
replaced, at the same time change-objects on the original source
string are created. The new source code is then validated against the
transformed AST nodes to ensure no bugs were introduced. If there is a
problem, pretty printing kicks in.

Lukas

-- 
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to