On Thu, Jun 26, 2008 at 4:27 AM, Mark Mahieu <<a href="mailto:mark@twistedbanana.demon.co.uk">mark@twistedbanana.demon.co.uk</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Neal,<br>
<br>
Given a method with the signature:<br>
<br>
void subscribe(Topic topic, {Message=>void} processor)<br>
<br>
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.<br>
<br>
Obviously I can get around this using a closure literal {Message msg => myPriorityQueue.offer(msg);}, however given:<br>
<br>
final class Processor {<br>
// ...<br>
void process(Message msg) {<br>
//...<br>
}<br>
}<br>
<br>
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.</blockquote>
<div><br>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. <br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
<br>
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)?</blockquote>
<div><br>I don't really have strong feelings about this one way or another. <br></div></div><br>