Automatic Resource Management, V.2
neal at gafter.com
Mon Apr 20 15:13:56 PDT 2009
On Mon, Apr 20, 2009 at 2:48 PM, Joshua Bloch <jjb at google.com> wrote:
> 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.
> 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:
>>> 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
>>>>> 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 (
>> 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