Feedback and comments on ARM proposal

[Mark Mahieu]

On 10 Mar 2009, at 16:33, Tim Peierls wrote:
> On Tue, Mar 10, 2009 at 12:18 PM, Neal Gafter <neal at gafter.com> wrote:
>
>> On Tue, Mar 10, 2009 at 8:36 AM, Tim Peierls <tim at peierls.net> wrote:
>>> the coin-dev list has yet to
>>> come up with an example where ARM support is both appropriate and
>> difficult
>>> to provide under the proposal.
>>
>> We identified a whole pile of them.  java.awt.Graphics,
>> org.eclipse.swt.graphic.Path, java.nio.channels.FileLock,
>> org.ietf.jgss.GSSCredential, and java.awt.image.VolatileImage to pick
>> a few.
>
>
> Even if you think that all of these are appropriate, I don't  
> believe that
> it's difficult to provide adapters.
>

I've been trying to flesh this out with real examples of adapters,  
and have ended up following a strangely circular path... no modifiers  
this time (promise!), but I'm starting to wonder whether a two- 
interface solution might not be such a bad idea after all, only with  
a twist.

Taking the SWT Resource class as an example, which cannot be  
retrofitted with AutoCloseable due to the clash with the Path  
resource's close() method, one might envisage a simple adaptation to  
look something like:


	class Resource {

		public void dispose() {
			// existing SWT clean-up method
		}

		public AutoCloseable toAutoCloseable() {
			return new AutoClosable() {
				public void close() { dispose(); }
			};
		}

		// etc
	}


Which could then be used:


	Path path = new Path(display);
	try (AutoCloseable dummyVar = path.toAutoCloseable()) {
		path.whatever();
		// etc
	}


Apart from the awkwardness of having to declare the dummy  
AutoCloseable variable, this quickly shows itself to be overly  
simple, as soon as we add a second Resource:


	Path path = new Path(display);
	Color color = new Color(display, r, g, b);
	try (AutoCloseable dummyVar = path.toAutoCloseable(), dummyVar2 =  
color.toAutoCloseable()) {
		path.setForeground(color);
		// etc
	}


Now we have the distinct possibility that the constructor invocation  
for 'color' will throw an exception, in which case 'path' will not be  
cleaned up.  And we can't use ARM to help.

We could extract interfaces for each of the Resource classes (IPath,  
IColor etc I'd imagine) and add toAutoCloseable() methods to each,  
which would return something that implements the appropriate  
interface + AutoCloseable.  I can't imagine the SWT API designers  
being wildly enthusiastic about that, but the resulting value could  
be used with ARM:


	try (AutoCloseablePath path = new Path(display).toAutoCloseable()) {
		path.whatever();
		// etc
	}


Muted applause all around.

But, what if there were an AutoCloseAdaptable interface, in addition  
to AutoCloseable:


	interface AutoCloseAdaptable {
		AutoCloseable toAutoCloseable();
	}


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.

It's just a thought, but does that sound vaguely workable, or have I  
drunk too much coffee again?


Mark