Hi Steph. It's not a question of preference.
you got me wrong. I introduced a preference based on hernan changes (for TDD) to avoid to have popup showing up all the time and I was wondering if this is this change that introduces this bug. | a | a + 1 was not related to shadowing but to variable usage. So now it may have also cancel the identification of shadow and this is what I asked lukas to check.
It's a question of cross-dialect compatibility and introducing future obscure bugs in Pharo.
I do not see why this is cross dialect compatibility? Is shadowing variable is not allowed in Smalltalk? In VisualWorks you get a pop up but you can define it. Now that the tool helps you to avoid them when you create them is different than the semantics level.
I'm in the process of debugging Compiler/Decompiler mismatch, and I can tell you the code is complex enough without shadowed variable. I'm quite sure you can get large breakage of debugger tool if you ever allow shadowed tempVars (say as a copiedValue defined inan optimized block).
probably.
Cheers
Before going to Pharo 1.0 final, could we please undo the compiler changes that handle the temporary variables?
1) In various code bases I see an increasing number of temp variables that shadow instance variables.
Yes this can be annoying we should find a solution in 1.1. http://code.google.com/p/pharo/issues/detail?id=2102
This can lead to subtle bugs in various situations that are very hard to debug. Furthermore consider that the code that shadows instance variables in unlikely to load into any other Smalltalk.
2) In various code bases I see an increasing number of unused temporary variables. Instead of just leaving them in there it would be nice if the compiler removed them right away.
http://code.google.com/p/pharo/issues/detail?id=2103
Point 1 is a *major* annoyance, I already lost hours for that reason.
Point 2 is not that important, as it has no intermediate consequences and can be deferred to code critics. I would need to write a new lint rule though.
If I knew where these compiler changes were done, I would propose a fix for Pharo 1.0 and 1.1. Any pointers?
Lukas
-- Lukas Renggli http://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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project