ARM Blocks: ease of use and for loops

[Howard Lovatt]

I can think of an example were changing the semantics of a for loop would
cause problems. If you open a resource, make a first pass over the data
collecting statistics, then go back and modify the data as a second pass,
and finally close the resource. I doubt this is common, but the example does
preclude modifying the for loop to see if a closeable iterator is used. (I
suspect as Neal has pointed out that in the majority of cases when people
iterate over the resource and don't immediately close it that they simply
forgot - but unfortunately there isn't much that can be done about that.)
It is for the above reason that I suggested separate types, for example
consider a file utility that currently iterates over the lines in a file,
this can be retrofitted with an ARM Closeable and an extra method, in
addition to the existing iterator from Iterable, that returns a
CloseableIterable. This way existing code isn't broken and the new closing
for loop construct can be used. Thus adding the extra types gives you fine
control.

If the extra types I suggested aren't liked then another option would be to
allow try to accept for each syntax, e.g. try ( x : resource ) { ... }, as
others have suggested. This has the same effect of giving fine control as
the extra types and it is a matter of style which is preferred (I have no
strong preference).

The SafeCloseable type is useful regardless of if anything is done with
for-each or not. Without an ARM close that doesn't throw an Exception code
that has no need to throw an Exception gets polluted with throws Exception
on any method that might close a resource and that then knocks onto methods
that call that method etc. You see this same effect with Callable because
there is no SafeCallable (Runnable doesn't return a value).

Glad to hear the prototype is coming along.

-- Howard.

2009/10/21 Neal Gafter <neal at gafter.com>

> On Wed, Oct 21, 2009 at 8:39 AM, Joshua Bloch <jjb at google.com> wrote:
>
>> I agree that this would be the right way to do it, but I'm not convinced
>> that it meets the bar for inclusion.  It's not a now-or-never thing: its and
>> independent change to for-each.
>
>
> Unfortunately, the shape of the language will affect the shape of libraries
> to come, and delaying this aspect of support for Closeable will push
> libraries in a less-than-optimal direction.  It is better to add support for
> Closeable all at once (or not at all).
>
>
>>  Two questions come to mind:
>> (1)  How big a win would this be in terms of expressiveness?  How often
>> (in a real code corpus) would it be applicable. How much nicer would the
>> code corpus be with this feature.  Or is it too magic?  (Shorter isn't
>> always better.)
>>
>
> In C#, the facility is used frequently.  Doing it "by hand" has all the
> disadvantages of boilerplate that both statement forms were meant to
> eliminate.
>
> Going back to a recurring theme: the present design (without supporting the
> for-each loop) fails to consider future evolution of the language.  For
> example, we'd regret not doing this now if we add support for iterator (or
> asynchronous) methods in the future.
>
> (2) Are there any dangers associated with it?  Suppose an existing final
>> class were retrofitted so that its iterator method returned a closeable
>> iterator. Then we'd be changing the semantics of an existing for-each over
>> that resource.  Is that a problem?
>>
>
> As explained before, it isn't a problem, primarily because the existence of
> such code, in conjunction with its use in a for-each loop, represents a
> resource leak in existing code.  I believe you'd be hard pressed to find in
> production use a single example of the kind of code whose behavior would be
> changed.
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>



-- 
 -- Howard.