[ImageJ-devel] [fiji-devel] Significant change to ImgOpener - or - why ImgOpener.openImg() cannot return a T

[simon.ochsenreither at googlemail.com]

Hi Barry,

Though Lion is instanceof Animal its not the case that Cage<Lion> 
> instanceof Cage<Animal>. This is counterintuitive but many people mention 
> it. 
>
> If it was the case you could write code like this:
>
> Cage<Animal> animals;
> Cage<Lion> lions;
>
> animals = lions; // This assignment is not allowed
>
> animals.add(rat); // If this executed, we'd have a Rat in a Cage<Lion>
>
> Even if you wrote 

Cage<? extends Animal> animals

It would allow the assignment of lions to animals ...

animals = lions;


... but would still need to disallow the addition of anything under Animal 
(because it is in a contravariant position).
 
That's the reason why in some situations wildcards don't add much benefit 
despite forcing people to write boilerplate.¹

The whole situation is made worse by some of the unreadable capture-of 
error messages produced from javac due to use-site variance and wildcards: 
https://gist.github.com/3229086
(Compare this with the error message from scalac: 
https://gist.github.com/3229104 ... the main issue is that Java code like 
that can sleep in the source code for years until someone tries to use it, 
while in Scala the code is rejected right at the declaration.)

The stuff javac does and sometimes doesn't is sometimes quite unfortunate. 
:-(

¹See also 
http://www.slideshare.net/marakana/effective-java-still-effective-after-all-these-years 
(p. 28)  in which using wildcards for return types is discouraged.

Bye,

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20120801/c8d5fd30/attachment.html>