[squeak-dev] Re: Cosmetic: move or remove a few temps inside
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:
| foo bar baz |
1 to: arg do:[:i| ...].
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
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? ...".
More information about the Squeak-dev