[squeak-dev] Re: Cosmetic: move or remove a few temps inside closures

Andreas Raab andreas.raab at gmx.de
Sun Dec 27 22:12:45 UTC 2009

Levente Uzonyi wrote:
> On Sun, 27 Dec 2009, Andreas Raab wrote:
>> Nicolas Cellier wrote:
>>> We shall now take the habit of declaring temps in inner scope possible
>>> and avoid writing in outer temps if possible.
>> Why? As long as auto-declare temps inserts temps at method level and 
>> auto-remove of unused temps simply fails for block-level temps, this 
>> policy would be annoying at best.
> Because the code is cleaner and faster. 

Cleaner? How so? Why are temps scattered throughout a method "cleaner"?
Faster? Which benchmark is improved? By how much exactly?

Not that I'm arguing all temps should always be at method level but 
neither do I think all temps at block-level should be considered the 
only acceptable variant. There is a trade-off which comes from various 
ways of using the tools (for example visibility of a temp during 
debugging) and the writer of the method should be allowed to decide 
which temps to move to block-level and which ones not. For example, 
there is absolutely no difference between:

mumble: arg
   | foo bar baz |
   1 to: arg do:[:i| ...].


mumble: arg
   1 to: arg do:[:i| | foo bar baz | ...].

(except that I find the latter slightly harder to understand) Just like 
with block-formatting, some people prefer it one way, some people the 
other and the one-size-fits-all approach of forcing one's own prejudices 
on everyone else is *extremely* problematic from my point of view. There 
is room for differences in writing code and just because they're 
different doesn't mean one way is strictly better and one way is 
strictly worse.

If there's an advantage for the compiler to have temps be block-local, 
then let the compiler deal with it, not the user. If we decide that we 
should encourage to define temps at the innermost block-scope then let's 
fix the tools to support that properly.

But rewriting hundreds of unrelated methods should always result in a 
*measurable* benefit not just some "uhm, I guess it's ... cleaner?  ... 
or maybe ... faster? ...".

   - Andreas

More information about the Squeak-dev mailing list