Retrofit Iterable to extend AutoCloseable

[Zhong Yu]

I think this is very different from adding some helper methods on
collection interfaces.

Adding close() to Iterator significantly changes how the interface
should be used. Old code ignorant of the close() method would now
become incorrect.

We can remedy this by requiring that any subclass with a non-trivial
close() must arrange to effectively trigger close() when the object is
GC-ed. However this is not an easy thing to do. (Maybe JDK can help us
here by providing a "destructor" utility like `void onGC(object,
action)`

Zhong Yu

On Mon, Nov 21, 2011 at 12:18 PM, Cleber Muramoto
<cleber at nightcoders.com.br> wrote:
> I've been following the list for a while, but I couldn't find any mention
> about this.
>
> I think it would be interesting for Iterable/Iterator to extend
> AutoCloseable providing a default no-op close(), allowing, for example, the
> creation Iterables backed by IO resources without the need to expose
> neither a specific interface nor the IO resource itself.
>
> Of course it would be much cooler if we had python-like yielders! But I
> think that this poor's man solution would suffice for a variety of use
> cases.
>
> Regards.
>
> Cleber.
>
>