Skip to main content

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

  • From: Jean-Marie Dautelle < >
  • To:
  • Subject: Re: Remove "generic" multiply/divide operations from Quantity
  • Date: Sun, 19 Oct 2014 18:18:29 +0200

Hello All,

Unit<?> is better than Unit without parameterized type. Also the second
issues warnings about the use of raw types.
Unit<?> makes a lot of sense in many cases, for example when we don't know
the unit type as: Unit<?> parseUnit(CharSequence)
The method Unit<Q> asType(Class<Q extends Quantity>) allows for proper
casting* with* runtime checking being performed. In other words you can
safely write:
    Unit<Velocity> km_per_hour =
KILO(METER).divide(HOUR).asType(Velocity.class); // Safe.
    Unit<Velocity> km_per_hour =
KILO(METER).times(HOUR).asType(Velocity.class); // Throws runtime error.
    Unit<?> km_per_hour = KILO(METER).times(HOUR); // If I don't care about
unit types.

I don't understand the issue with JDK8 since all of the above works well
with JDK1.5+
Cheers,
JM


On Sun, Oct 19, 2014 at 5:15 PM, Martin Desruisseaux <
>
 wrote:

> Le 20/10/14 00:09, Werner Keil a écrit :
> >
> > It however looks like especially the Output of Unit<?> is going to
> > cause us trouble in JDK8+ ;-/
> >
> This question should be over for a long time: there is no other possible
> output for multiply/divide/inverse/pow operations, no matter how we turn
> the problem, except if we provide a Class argument.
>
> I'm in the process right now to write an email to the OpenJDK mailing
> list for making that clear. But I will submit it to this list before to
> send it - I will not send it without authorisation.
>
>
> > The reflect() method of ReflectionDemo won't compile with Unit<?>
> > either for input parameters coming from at least a "chain" of
> > wildcards like Unit.multiply(Unit<?>).asType() which again throws out
> > Unit<?>.
> >
> I will look at that tomorrow.
>
>
>     Martin
>
>


-- 
It is not the strongest of the species that survives, nor the most
intelligent. It is the one that is most adaptable to change. - Darwin's
Origin of Species (digest)


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

(continued)

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

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

Martin Desruisseaux 10/19/2014

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

Werner Keil 10/19/2014

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

Martin Desruisseaux 10/19/2014

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

Jean-Marie Dautelle 10/19/2014

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

Martin Desruisseaux 10/19/2014

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

Werner Keil 10/19/2014

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

Werner Keil 10/19/2014

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

Martin Desruisseaux 10/19/2014

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

Werner Keil 10/19/2014

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

Martin Desruisseaux 10/19/2014

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

Werner Keil 10/19/2014

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

Martin Desruisseaux 10/19/2014

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

Werner Keil 10/19/2014

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

Martin Desruisseaux 10/19/2014
 
 
Close
loading
Please Confirm
Close