Automatic Resource Management, V.2

[Neal Gafter]

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

> Neal,
> If you have a nice design, feel free to share it with the rest of us.
>

I think you know I believe this problem space is best addressed by APIs
rather than (less flexible) language features.  Still, I repeat my
suggestion that you look at the C# solution as a starting point.


>
>         Josh
>
>
> On Mon, Apr 20, 2009 at 2:32 PM, Neal Gafter <neal at gafter.com> wrote:
>
>> 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.
>>
>
>