Method reference assignment compatibility

[Neal Gafter]

On Thu, Jun 26, 2008 at 4:27 AM, Mark Mahieu <mark at twistedbanana.demon.co.uk>
wrote:

> Neal,
>
> Given a method with the signature:
>
>        void subscribe(Topic topic, {Message=>void} processor)
>
> I might want to pass myPriorityQueue#offer(Message) as the second argument,
> but this isn't permitted since Queue<E>#offer(E) has a boolean rather than
> void result type.
>
> Obviously I can get around this using a closure literal {Message msg =>
> myPriorityQueue.offer(msg);}, however given:
>
>        final class Processor {
>                // ...
>                void process(Message msg) {
>                        //...
>                }
>        }
>
> In Java 6, if I were to alter the process(Message) method to return a
> value, such as a boolean indicating success or failure of the operation,
> then I'd break binary compatibility but I think source compatibility would
> be preserved.


No, this breaks source compatibility.  Another class might extend Processor
and implement an interface, and use the inherited process(Message) method as
an inherited overrider.


> Under BGGA, if I had used a method reference myProcessor#process(Message)
> as the argument to the subscribe() method above, then this API change will
> have broken source compatibility.
>
> So my question is: would it be problematic to allow a method reference with
> a non-void result type to be assignment compatible with an interface or
> function type with a void result type (all other conditions being
> satisfied)?


I don't really have strong feelings about this one way or another.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20080626/fce5eb14/attachment.html