Re: Blocks for scope control
On 15.01.2012 22:49, Arved Sandstrom wrote:
On 12-01-15 03:00 PM, Lew wrote:
Arved Sandstrom wrote:
You see it standardly in initialization blocks, especially static,
though I often (more often than not) find myself refactoring static
initialization blocks to private static methods. For instance
initialization they're extremely useful for blocks that multiple
constructors must share.
At the instance and class levels, it's true, these blocks operate
similarly to "local" blocks.
That's also a feature I use from time to time. But I thought this
discussion was more about blocks inside methods since initializer blocks
are a quite different beast (you can view them as anonymous methods
without arguments and return type).
Within methods I use them as well, to enforce temporariness of
variables. This is very handy to prevent re-use of a variable whose
usefulness has expired. The need is rare, but like the legendary
left-handed stembolt, if you don't have it when you need it, that's a
worry.
This is exactly the use I was calling out. After visibility modifiers we
then have a number of levels of scope - class, instance, method and
block. We already use restrictive variable scoping in blocks; everyone
who re-uses for-loop index names benefits from this.
My point is simply that on some occasions, as you point out yourself,
you do want to "enforce temporariness" of a variable in a scope narrower
than that of its enclosing method. The answer here, on those infrequent
occasions where it makes sense to use a block, is not to blindly create
a new method simply to get variable scoping. That reflexive practice can
lead to unreadable fragmented code.
But there are other blocks which also restrict scope (i.e. flow
control). So more often than not I find myself using those. Plus, I
now have made it a habit to make variables final as often as possible
(mostly for documentation reasons) and thusly also prevent accidental reuse.
Regarding the method refactoring argument: if there is so much code and
hence so many local variables that you want to use blocks to introduce
smaller scopes chances are that the logic within that blocks is also
largely independent from the code around so it is a good candidate for
refactoring anyway. The reason for refactoring into methods isn't the
scope but the independent logic.
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/