Skip to main content

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

  • From: Werner Keil < >
  • To:
  • Subject: Re: Remove "generic" multiply/divide operations from Quantity
  • Date: Sun, 19 Oct 2014 19:52:19 +0200

Am 19.10.2014 19:08 schrieb "Martin Desruisseaux" <
>:
>
> Le 20/10/14 01:34, Werner Keil a écrit :
>
>> Users, e.g. those from hig profile Eclipse IoT projects could tell us,
if being forced to cast would make them abandon the JSR for another
alternative (well I did not ask them about abandoning, but if cast was
annoying or show stopper for their needs;-)
>
> UNITSOFMEASUREMENT-62 is unacceptable, and the fact that Eclipse IoT like
to cast or not will never change anything to that. Neither you or me or
anyone else in this group can have any word on that. It is unacceptable,
period. You can propose other alternatives, like removing parameterized
type completely from the whole JSR-363 project (the pros and cons would
have to be weighted), but not apply UNITSOFMEASUREMENT-62.
>
>
>> There was never anything that could prevent users of the API from doing
"stupid" things like:
>> Quantity<Energy> speed = (Quantity<Energy) distance.divide(time);
>
> But they get a warning! I repeated that many, many times!!! By contrast,
UNITSOFMEASUREMENT-62 wrongly shutdown all warnings - it causes the Java
parameter type system to lie. Furthermore - repeating myself again and
again - we should encourage (not force) the user to cast to (Energy)
instead of (Quantity<Energy>) when he can. The former is safe, the later is
not. This is the same approach than casting Comparable<?> or Enum<?> to
their specific subclasses. E.g. casting an Enum<?> to (Enum<LinkOption>) is
unsafe, while casting to (LinkOption) is safe.
>

Without repeating myself, the cast to Energy fails miserably.
I tried to revive your Reflection based approach, but no operations like
add(),... works. And for ME 8 Reflection is useless.
Every implementing class like DoubleQuantity, etc. has no knowledge of
Energy at runtime, nor a chance to return it unless Java gets reified
generics.

So the only way you might get Energy or return it without a
ClassCastException would be concrete classes for every interface, including
those not yet defined like BMI, etc.
Or what would you use if you need to return the BMI in your "interface aim"?

As of now except the old factory out of touch with the rest of the system
nothing takes say Energy.
If you managed to create Length via that old factory you might pass it to
another Length's multiply() method, but you get
Quantity<?> which you could cast to Quantity<Area> (or Quantity<Mass> again
the compiler doesn't give a shit and no exception even at runtime is thrown
there;-)
If you however try to cast it to Area or Mass both will fail with a
ClassCastException.

So the only consequent way except for concrete classes like LengthAmount
will always be using Quantity<> (something including? ) or abandon ALL
methods that Measurement has from Quantity and leave that to
imolementations.
Leaving say multiply(Number) to return Quantity<Q> and a concrete class
with a multiply(Length) returning an interface like Area would cause mayhem
and confusion.

So with exceptions of a few lesser frequent methods like invert() I'd say
it's all or none, regardless of their concrete signature.

Nice you mention Enum, it uses exactly the signature, Otavio suggested
since Java 5;-)
http://docs.oracle.com/javase/6/docs/api/java/lang/Enum.html

Enum<E> allowing you to apply <?> but the API does not use any wildcard.
valueOf() takes a somewhat similar argument like asType(), which seems
rather typesafe by itself, but as soon as combined with all wildcard
methods like multiply() or divide() it breaks on a regular basis on SE 8+
About 200 or so cases in our implementations of SystemOfUnits alone, that's
not "cornerstone" and if we return something, other APIs or apps cannot
use, then this JSR failed its job;-|
>
>> With Otavio's suggestion the "stupid" declaration would be restricted to
the left side of the operation instead of doing it twice. A bit like
Diamond knowing the type from the left side;-)
>
> No it is not like the diamond operator. The diamond operation is applied
when the compiler is able to prove that the inferred type is correct. This
is not an "accept any crap the user is putting there" operator!
>
>
>> Let's see, if JDK guys (or potential users) see a major problem with the
existing signatures.
>
> If by "existing" you mean the UNITSOFMEASUREMENT-62 ones, of course they
will see a major problem!
>

No, existing is like in Unit and other parts of Quantity, Otavio's
suggestion was applied in a single place to show the difference.

>
>> Users (especially from IoT) were clear, they won't accept an artificial
>> multiply(Argument<?>, Class<?>) option.
>
> I do not support a multiply(Argument<?>, Class<?>) method neither. I
mention it only because such method (even if I do not like it) is on the
list of possibilities that the JSR-363 group can choose, together with
accepting the Unit<?> and Quantity<?> return types (my preferred choice),
removing all parameterized types, removing all operations except add and
subtract, etc. But UNITSOFMEASUREMENT-62 is not on the list of things we
can choose.
>
>     Martin
>


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

(continued)

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

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

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

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

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