Skip to main content

Re: Remove "generic" multiply/divide operations from Quantity

  • From: Martin Desruisseaux < >
  • To:
  • Subject: Re: Remove "generic" multiply/divide operations from Quantity
  • Date: Sat, 18 Oct 2014 18:05:05 +0900
  • Organization: Geomatys

Werner, you still do not understand the problem.

The UNITSOFMEASUREMENT-62 method signature tells to the compiler "/the
return type of the multiply operation is whatever //it is going to be
assigned to/". So of course it compiled, since the compiler adapted the
multiply return value to whatever addUnit wants. *But it still wrong.*
The result of a multiplication depends only of its arguments, no of the
caller's desire.

Werner, you seem to take "it compile" or "it doesn't compile"
observations as the only criterion for determining if what we are doing
is correct. Why you never discuss about the semantic of the operations?

On your last quote from the Java tutorial ("/Using a wildcard as a
return type should be avoided/"), why the implicit "/when semantically
correct/" complement was not obvious to you?

    Martin



Le 17/10/14 12:26, Werner Keil a écrit :
>
> Well believe it or not, a non-wildcard signature like Otavio proposed
> it seems to solve another problem in Unit systems;-)
>
> An almost ancient helper method from JSR-275 times (which remained in
> JScience and all other implementations) looks like this:
>
> private static <U extends Unit<?>> U addUnit(U unit) {...
> Adding a given unit to a set of units.
> This notoriously failed with a "Upper type boundary" compile error
> under SE 8 at least since U20.
>
> Imagine what happened, when I changed it to
> private static <U extends Unit<Q>, Q extends Quantity<Q>> U addUnit(U
> unit) {...
>
> The problematic line involving POUND_FORCE suddenly was accepted
> unchanged from the RI equivalent;-)
>
> Here's what the JDK team says about the use of wildcards:
> http://docs.oracle.com/javase/tutorial/java/generics/wildcardGuidelines.html
>
> "Using a wildcard as a return type should be avoided..." ;-)
>
> Werner
>



Re: Remove "generic" multiply/divide operations from Quantity

(continued)

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Leonardo Lima 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Jean-Marie Dautelle 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/17/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/17/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/17/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/18/2014

Re: Remove "generic" multiply/divide operations from Quantity

Leonardo Lima 10/17/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/18/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/18/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/18/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/18/2014

Re: Remove "generic" multiply/divide operations from Quantity

Leonardo Lima 10/18/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/18/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/18/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/18/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/18/2014
 
 
Close
loading
Please Confirm
Close