Automatic Resource Management, V.2

Joshua Bloch jjb at google.com
Mon Apr 20 14:48:36 PDT 2009


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

        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.
>



More information about the coin-dev mailing list