ARM Blocks: ease of use and for loops
kevinb at google.com
Wed Nov 11 12:06:20 PST 2009
I realized that this is not as useful as I was hoping it would be.
Many users at Google are not iterating through the source data directly, but
are passing that iterator through methods like transform() and filter() and
many others (
I can't stand the thought of having to descend into RandomAccess-style hell,
so passing an iterator through these methods will likely wipe the Closeable
right off, making the foreach improvement less applicable.
I withdraw my +10, which is not to say that I am arguing against it.
On Sun, Nov 8, 2009 at 8:09 AM, Kevin Bourrillion <kevinb at google.com> wrote:
> I think detecting 'iterator instanceof Closeable' is an outstanding
> idea, and one that would solve problems that have been vexing me as a
> library developer for years.
> The foreach construct owns the creation of that instance, and is the
> only party that has a reference to it. If the instance is Closeable,
> it feels simply irresponsible to ignore this.
> As for the potential risks, we're talking about an instance that's
> unreachable and eligible for GC, so it's difficult to imagine that
> closing such an instance could be a bad idea. Looked another way, if
> a user didn't want automatic close for some reason, that reason would
> already be preventing that user from using foreach anyway.
> On Thu, Oct 22, 2009 at 8:19 AM, Neal Gafter <neal at gafter.com> wrote:
> > On Thu, Oct 22, 2009 at 8:59 AM, Howard Lovatt <howard.lovatt at iee.org
> >> I think you can choose if close to applies to the Iterable or the
> > Agreed. But if it applies to the Iterable, the programmer can easily use
> > ARM block around the for-each loop. If it applies to the Iterator, there
> > no way for the programmer to do it. That's why support is needed in that
> > case.
> Kevin Bourrillion @ Google
> internal: http://go/javalibraries
> external: guava-libraries.googlecode.com
Kevin Bourrillion @ Google
More information about the coin-dev