Use Advanced Search to search the entire archive.
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 18:34:15 +0200
Well it certainly isn't when it comes to breaking code in Java 8, 9 or 10;-)
Please do, a key question is, whether those wildcard results (or arguments,
see the method in ReflectionDemo) cause trouble and should be rephrased.
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;-)
There was never anything that could prevent users of the API from doing
"stupid" things like:
Quantity<Energy> speed = (Quantity<Energy) distance.divide(time);
Each being typed Length and Time.
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;-)
The compiler currently warns you, "You must cast" not, what to cast to,
hence neither form provides any semantic value like for add(), subtract()
or to() as well as their ciunterparts on Unit.
Let's see, if JDK guys (or potential users) see a major problem with the
existing signatures.
Users (especially from IoT) were clear, they won't accept an artificial
multiply(Argument<?>, Class<?>) option.
If asType() similar to Unit provided any help or guidance, maybe that, they
are free to use it and of course the result would have to work in SE8+, too.
Werner
Am 19.10.2014 17:16 schrieb "Martin Desruisseaux" <
>:
>
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
>
>