what you could do is to provide a cheap and dirty couple of methods
"this method used a trivial and may be incorrect strategy to determine whether the
receiver is the superpseudo variable"
like that we can be happy
On May 29, 2010, at 11:32 PM, Lukas Renggli wrote:
why we cannot
simply know if a variable is named super and self.
Of course, you can simply write
aVariableNode name = 'self'
and then you know that your variable is called 'self', but nothing
more. I am not saying that this is wrong, it is likely to be correct
in most cases and probably enough for most code analysis scenarios.
IMHO, it should then also written like that to reveal its intention.
Because normally it should be accepted as
something by the compiler
or we should fix the compiler.
The Pharo compiler does not compile code with
instance/temporary/argument variables that shadow 'self', 'super',
'thisContext', 'true', 'false', or 'nil' (Jorge fixed
other compilers might not insist on that, or you might end up with
syntactically correct code that never went through a semantic checker.
For example, the following code is syntactically perfectly valid
| thisContext |
super := self
Also there is an infinite number of ways variables can be shadowed
without going through the compiler and without anybody complaining.
And there are not even 'dirty' tricks needed to do that, just
add/remove instance-, class-, or global variables in the context of
existing code. In this situation anything simpler than AST-Semantic
most certainly leads to wrong results.
Again, I am not saying that you have to use AST-Semantic. It is a tool
that is useful if you need precise semantic information, for example
for code transformations (Helvetia), a compiler (maybe the New
Compiler in the future), or for semantic preserving refactorings
(maybe the Refactoring Engine in the future).
Moose-dev mailing list