[Pharo-project] Bug or new feature in RB?
Hi Lukas. I was playing around RB (actually, looking at your screencasts) and I found something weird. Steps done: 1) Go to AST, "refactoring scope" -> "package" 2) There, took class RBReplaceRule and "refactor method" -> "rename" to the method initialize 3) Proceed -> yes There you will see the list of the initialize methods that it will apply the refactor. As you can see, all classes affected are RB, BUT Behavior and CompiledMethod. This is because the package AST has extensions to both classes. But NONE of those extensions are with the initialize method, but with parseTreeFor: and parseTree, So, my question is, shouldn't only apply the refactor to the initialize method of extended packages ONLY if that method is extended ? Because otherwise I think it is a bit dangerous. What do you think ? I attach screenshot also. Cheers Mariano
So, my question is, shouldn't only apply the refactor to the initialize method of extended packages ONLY if that method is extended ? Because otherwise I think it is a bit dangerous.
What do you think ?
I attach screenshot also.
I see no screenshot, but I can reproduce the problem. The problem is that for some refactorings the refactoring engine needs too look beyond the defined scope to be able to do something useful (e.g. if a class is not contained in a scope but some methods, it still needs some object that represents the class to enumerate the methods). There are definitely issues when classes are not fully contained within a scope, but I don't think that this is critical. After all the changes are presented for review. Lukas -- Lukas Renggli www.lukas-renggli.ch
On Wed, Apr 7, 2010 at 2:09 PM, Lukas Renggli <renggli@gmail.com> wrote:
So, my question is, shouldn't only apply the refactor to the initialize method of extended packages ONLY if that method is extended ? Because otherwise I think it is a bit dangerous.
What do you think ?
I attach screenshot also.
I see no screenshot, but I can reproduce the problem.
Thanks Lukas. I forgot the screenshot...but I guess you already understood so it has no sense.
The problem is that for some refactorings the refactoring engine needs too look beyond the defined scope to be able to do something useful (e.g. if a class is not contained in a scope but some methods, it still needs some object that represents the class to enumerate the methods). There are definitely issues when classes are not fully contained within a scope, but I don't think that this is critical. After all the changes are presented for review.
Ok, thanks for the explanation and the consideration. I just wanted to be sure it was not an easy bug/fix. Cheers Mariano ps: did I already said that waiting 13 hours in a airport is boring ? Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (2)
-
Lukas Renggli -
Mariano Martinez Peck