> 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 >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
