Feedback and comments on ARM proposal

Joshua Bloch jjb at google.com
Thu Mar 12 21:13:32 PDT 2009


Mark,
A problem with the AutoCloseAdaptable approach, which Bob Lee pointed out,
is that the emitted code would end up calling the close method of an object
whose static type was AutoCloseable.  Unfortunately, AutoCloseable's close
method throws Exception, which means that the enclosing automatic resource
management statement would throw Exception.  I'm afraid that that this rules
out the approach:(

              Josh

On Tue, Mar 10, 2009 at 4:36 PM, Mark Mahieu <markmahieu at googlemail.com>wrote:

> Hi Josh,
>
> On 10 Mar 2009, at 21:51, Joshua Bloch wrote:
>
>  Tim is a bigger fan of adapters than I am (for this purpose).  To the best
>> of my recollection, 3 of the 5 types above could be retrofitted to implement
>> AutomaticallyCloseable, and I think that's a better solution where it works.
>>
>
> No argument there :)
>
>
>>
>> If ARM recognised this interface, and called the toAutoCloseable()
>> method behind the scenes (waves hands), Resource could be made to
>> implement AutoCloseAdaptable very simply, and we could write this:
>>
>>
>>       try (Path path = new Path(display)) {
>>               path.whatever();
>>               // etc
>>       }
>>
>>
>> Which is exactly what we'd want, I think.
>>
>> This is a possibility.  It still doesn't work for interfaces, but I can't
>> imagine a class for which it doesn't work.  That said, I'm not sure I prefer
>> it to a simple two-interface proposal (AutoCloseable + AutoDisposable).  I
>> suspect that this combination would enable retrofitting of nearly every
>> class that could benefit from the facility.  I understand that it's
>> unsatisfying, but it's simpler than the AutoCloseAdaptable approach.
>>
>
> Perhaps this does come down to how well a given variation meshes with
> interfaces.
>
> I mean, I pity poor Jean-Luc, who brushes his teeth before bed every night,
> pays his taxes on time, and prefers to expose interfaces from his APIs.
>  Sadly, he named his disposal method 'fermer', and can't retrofit
> AutoCloseable or AutoDisposable onto his interfaces without breaking code
> downstream.  So he's stuck with an adapter approach anyway, only he can't
> decide whether it should return an AutoCloseable or an AutoDisposable, poor
> guy.
>
> ;)
>
> But seriously, it probably is a minor detail.  Thanks for taking the time
> to read through my suggestion.
>
> Regards,
>
> Mark
>
>



More information about the coin-dev mailing list