Automatic Resource Management, V.2

[Neal Gafter]

On Mon, Apr 20, 2009 at 2:07 PM, Joshua Bloch <jjb at google.com> wrote:

> Neal,
> On Mon, Apr 20, 2009 at 1:35 PM, Neal Gafter <neal at gafter.com> wrote:
>
>> On Mon, Apr 20, 2009 at 1:26 PM, Joshua Bloch <jjb at google.com> wrote:
>>
>>> As for the "AutoCloseableItertor" stuff, I think it can wait for a
>>> subsequent release. I see it as scope-creep that distracts from the
>>> central
>>> goals of the proposal and reduces the likelihood that it will be
>>> successfully delivered into Java 7.
>>
>>
>> If you don't design this now, you may well find it impossible to add later
>> without introducing a breaking change.
>>
>
> That's always possible.  I'm not averse to thinking about it once the main
> work is done.
>

That's a reasonable approach, if you don't mind redoing the main work once
that thinking is done. The risk is that you'll have too much invested in the
design by that time to be flexible about addressing this.


> In C# (as you know) IEnumerator extends IDisposeable.
>

I don't know that because it is not true.  IEnumerator does not extend
IDisposable (
http://msdn.microsoft.com/en-us/library/system.collections.ienumerator.aspx),
though IEnumerator<T> does (
http://msdn.microsoft.com/en-us/library/78dfe2yb.aspx).  So as you can see,
that's not necessary to get the desired behavior.


> we'd need to add the notions of AutoCloseIterable, whose iterator method
> returns an AutoCloseIterator, which extends both AutoCloseable and Iterable.
> The we'd have a for-each method whose behavior differed depending on the static
> type of its iterable.  This is a bit scary, in that it violates a
> fundamental API design guideline.
>

"need" is too strong a word; that is simply one design option, and I agree
that this may be a poor starting point.  However, if a solution isn't
included when the feature is introduced, you may end up forcing this design.