Change of Dimension breaks implementations

[GoogleCodeExporter]

Unfortunately, the statement: "This should not have any impact on existing 
code."
in
>Use <? extends ...> for parameters of collections being returned; otherwise 
>more specialized collections cannot be returned by implementing classes. 
>Tthis should not have any impact on existing code.

hasn't quite applied.

At least 2 previously fine codes in the UOMo implementation require a recast 
to: Map<Unit<?>, Integer> productUnits.

Maybe rewriting that could relieve from such casts, but the original code 
worked fine until the interface changed.

Original issue reported on code.google.com by werner.k...@gmail.com on 13 Oct 2010 at 2:36

[GoogleCodeExporter]

Sorry about that. I did not know about the UOMo implementation. Would it be 
possible for the UOMo implementation to be corrected?

The problem with declaration such as Map<Unit<?>>, Integer> methods is that it 
cannot be overridden to return a more specialized type (this was a mistake). 

But using Map<? extends Unit, Integer> instead allows things such as:
    class FinancialUnit implements Unit {
          Map<? extends FinancialUnit, Integer> getProductUnit() { ... } 
              // A financial unit is always made up of financial units.
     }

Original comment by daute...@gmail.com on 13 Oct 2010 at 4:08

[GoogleCodeExporter]

It's not the only implementation, but hopefully GeoAPI may not be as affected 
here?

I understand this is e.g. for extensions by anonymous inner classes like the 
example, but especially finacial specs and APIs, even recently discussed Money 
JSRs could profit, so in a RC or Milestone stage this shouldn't be too tragic.

Original comment by werner.k...@gmail.com on 13 Oct 2010 at 6:41

[GoogleCodeExporter]

Original comment by werner.k...@gmail.com on 5 Nov 2010 at 6:27

• Changed state: Fixed