Virtual Extension By Inversion of Responsibility (Second Draft)

[Stephen Colebourne]

This has similarity to my first thoughts on the topic -
http://www.jroller.com/scolebourne/entry/java_7_extension_methods

I now feel that a key aspect of the problem space is to permit
different implementations of an interface like List to provide
different implementations of the extension method. Ideally, I'd still
like to be able to effectiveyly add to the API as well (as this
proposal does). I want to have my cake and eat it.

My concern with the current defender methods approach is that it
appears to contain a lot of moving parts. As such, I don't currently
have a preferred solution to this space - just the requirements listed
above.

Stephen


On 18 June 2010 05:39, Neal Gafter <neal at gafter.com> wrote:
> Colin-
>
> I like some aspects of this proposal.  Compared to defender methods,
> there is no need for a special InterfaceName.super.method(...)
> notation.  I like that it can be used to extend interfaces over which
> the programmer does not have control: that enables pattern-based
> frameworks and language extensions to be more generally useful (ala
> LINQ).  An example of where that would be useful today is in the
> specification of ARM blocks; if defined in terms of -> instead of .,
> it can be retrofitted to many more types than would otherwise be
> possible.  Defender methods don't allow that.
>
> I don't like the use of annotations (@ExtensionSupport and
> @ExtensionTarget) to change the meaning of declarations; this could be
> done with context-sensitive keywords instead.  It is a little
> unfortunate that the syntax is distractingly different from an
> ordinary method invocation, even though the reader usually doesn't
> care (now we'd have three different invocation syntax forms).
>
> Cheers,
> Neal
>
> On Thu, Jun 17, 2010 at 8:09 PM, Collin Fagan <collin.fagan at gmail.com> wrote:
>> Hi Everyone,
>>
>> I've put together a second draft of my proposal for virtual extension
>> methods.
>>
>> http://www.box.net/shared/r24vvgma5p
>>
>> And yes *this* time they are really virtual. I welcome all comments.
>>
>> Thanks,
>>
>> Collin
>>
>>
>
>