Feedback and comments on ARM proposal

[Mark Mahieu]

Hi, Josh.

Yes, I see, that's clearly unacceptable.  And we know that adding an  
exception type parameter to AutoCloseable leads to other problems.

I guess trying to silently slip the adapter into the Resource class  
structure, without requiring the user to go through any additional  
steps, is a trick too far.  In any case, since that can't always be  
done when the resource types are interfaces, it's probably better to  
have a uniform approach to adapters if they're going to be necessary.

I think we've now illustrated a couple of reasons why an adapter  
method returning an AutoCloseable directly, will not work well.  It  
doesn't fit with ARM's variable declarations, and Bob's point about  
the exception type would be equally valid with that approach.

It may be worth persevering with the Adapter interface for a little  
longer though, as it is something we can parameterize with the  
exception type.  If it's going to be returned by an adapter method  
rather than implemented directly by the resources, perhaps the  
Adapter interface should extend AutoCloseable itself:


	interface AutoCloseableAdapter<X extends Exception>
		extends AutoCloseable {
		
		void close() throws X;
	}


That's certainly simpler than the version I suggested previously,  
although the name probably isn't ideal.

Another aspect of my earlier suggestion that I find somewhat  
troubling is the way in which ARM would need special handling for two  
essentially unrelated interfaces.  That feels messy, but I think the  
version above improves matters in that respect, since  
AutoCloseableAdapter would now be a specialization of AutoCloseable.

I can see where I'm going to end up with this.  The next step will be  
that I suggest we add a method to the Adapter type in order to allow  
ARM to retrieve the resource.  This would then give us all the  
information ARM requires in one neat little interface (which would  
still need a better name):


	interface AutoCloseableAdapter<T, X extends Exception>
		extends AutoCloseable {
		
		T resource();

		void close() throws X;
	}


At this point it's starting to look very similar to the interface  
which Neal has just put forward for consideration, but with slightly  
different trade-offs and applicability.

The main concern I have about this approach in general is that the  
variable declaration might be a little too 'magical' : you appear to  
start out with a resource (a Path, to continue previous themes), call  
a method to turn it into something completely different, then assign  
that to a variable of the type you started out with.  Possibly a bit  
confusing, given a syntax that uses the assignment operator anyway.

Hmmm.

Mark


On 13 Mar 2009, at 04:13, Joshua Bloch wrote:

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