ARM Blocks: ease of use and for loops

[Howard Lovatt]

I think you can choose if close to applies to the Iterable or the Iterator.
EG consider a user choosing a file and then printing it (or any other
example where you want to configure an object and then grab the resource and
iterate over it - i.e. lazy grabbing). If close applies to the iterator then
you might write:
    final InFileCloseableIterator cIterator = new InFileCloseableIterator();
    cIterator.choose(); // User chooses file
    for ( final String msg : cIterator ) { // Opens chosen file
      System.out.println( msg );
    } // Closes chosen file

If close applied to the Iterable then the action would be split across a
choosing object and an Iterable object, e.g.:

    final FileChooser chooser = new FileChooser();
    chooser.choose(); // User chooses file
    for ( final String msg : new InFileCloseableIterable( chooser ) ) { //
Opens chosen file
      System.out.println( msg );
    } // Closes chosen file

The latter example, close applies to Iterable, can also use the current
for-each and the proposed try without an expanded for-each fairly easily,
e.g.:

    final FileChooser chooser = new FileChooser();
    chooser.choose(); // User chooses file
    try ( final FileCloseableIterable cIterable = new
InFileCloseableIterable( chooser ) ) { // Opens chosen file
      for ( final String msg : cIterable ) {
        System.out.println( msg );
      }
    } // Closes chosen file

The former example, close applies to Iterator, requires the compiler to do
more to expand the for-each (see original post in this thread).

I find the former, close applies to Iterator, more in keeping with Java
collections; but it is more a matter of taste rather than one is definitely
better than the other, or did you have a specific example in mind for why
you favor close applying to the Iterable?

 -- Howard.

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

> On Thu, Oct 22, 2009 at 12:23 AM, Howard Lovatt <howard.lovatt at iee.org>wrote:
>
>> 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.)
>
>
> I can't imagine why such an API would retrofit the Iterator rather than the
> Iterable with Closeable.  Besides being wrong, I expect such code is not
> just uncommon, but nonexistent.
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>



-- 
 -- Howard.