Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Blocks for scope control Date: Mon, 16 Jan 2012 07:55:58 +0100 Lines: 54 Message-ID: <9ni009F82hU1@mid.individual.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net kY8GpsqvSK1O80R5LV196AII+qZFMrmL6UUo66eQ9xayuBZSU= Cancel-Lock: sha1:1laf7uCXTtdMYlI9JvXPG+Cqruc= User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:11372 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/