then excellent!
Stef
On May 30, 2010, at 10:18 AM, Lukas Renggli wrote:
There is already #isSelfSend and #isSuperSend in RBMessageNode from John Brant.
Lukas
On 30 May 2010 09:53, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
what you could do is to provide a cheap and dirty couple of methods
fuzzyIsSuper "this method used a trivial and may be incorrect strategy to determine whether the receiver is the superpseudo variable" fuzzyIsSelf
like that we can be happy
Stef
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 that). However 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 Smalltalk:
foo: self | thisContext | super := selfAlso 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).
Lukas
-- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli www.lukas-renggli.ch
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev