lambda syntax tutorial

[Rémi Forax]

Le 05/08/2010 18:22, Kevin Bourrillion a écrit :
> Agreed, adding an overload can sometimes be source-incompatible today, 
> even for a final class.  But in how many ways can this happen?  I'm 
> only thinking of one so far: if there could exist any list of actual 
> parameter types that would become ambiguous.  (If one of my signatures 
> is a refinement of the other, I should have no problem, since I should 
> darn well be making sure the two have equivalent behavior for the same 
> inputs anyway).
>
> This is pretty simple for me to watch out for in my API changes to my 
> released libraries.  And, I sometimes even have recourse to avoid it: 
> for example if I have only
>
>   String join(Iterable<?> iterable);
>
> and I want to add
>
>   String join(Iterator<?> iterable);
>
> I believe I can do this source-compatibly if I also add at the same time
>
>   @Deprecated
> <T extends Object & Iterator<?> & Iterable<?>> String join(T iter) {
>     return join((Iterable<?>) iter);
>   }
>
> (I'm planning to try exactly this in Guava.  Yes, I think it's as lame 
> as anyone that a class would implement both of those types.  Still, I 
> like knowing my changes are completely compatible.)

In fact, there is a trick, you can just add:

<T extends Iterator<?>> String join(T iterator) { ... }

because it's a parametrized method, join(Iterable) will be selected 
first if a class implements both types.


>
> So, my question is: to what degree does the current proposal expand 
> the set of categories of source-incompatible API additions we can 
> make?  And how workaround-able are those?  For example, if Foo#bar has 
> no contextual smarts at all, then adding overload #2 of any method 
> would /always/ be source-incompatible (which would be hideous!).  So 
> how much intelligence does it have?

I think we have no degree of freedom if the syntax doesn't specify the 
parameter types.

>
>
> P.S. fun trivia if you haven't heard it: my colleague once found a 
> case where adding overload C caused previous source references to 
> overload A to suddenly be compiled as references to overload B!  Ahh, 
> fun times.
> http://twofoos.org/content/java-type-system-holes/
>

Rémi