Use Advanced Search to search the entire archive.
Re: Email proposal to the core-libs-dev@openjdk.java.net
- From: Martin Desruisseaux <
>
- To:
- Subject: Re: Email proposal to the
- Date: Mon, 20 Oct 2014 23:48:39 +0900
- Organization: Geomatys
Hello Werner
Le 20/10/14 20:08, Werner Keil a écrit :
>
I am pretty sure, a semantic connection between input and output will
>
never be available in Java.
I also believe that no such connection will be available in the
foreseeable future. For this reason, I believe that we should not omit
the multiply / divide / pow / invert methods, since I don't see when
they could be reintroduced with accurate type parameters. Consequently
if we keep those methods and choose to not remove completely
parameterized types in the whole project, I see only two solutions:
1. The Quantity<?> / Unit<?> return type.
2. Or add a Class<R> argument in multiply / divide / pow / invert methods..
If I'm understanding well, Werner told us that peoples on the Eclipse
side do not like option 2. I do not like option 2 neither. Furthermore,
option 2 imposes an unnecessary performance cost on users who do not
need to cast (i.e. on users who assign the result to a variable of type
Quantity<?>), or in intermediate calculation (i.e. in
A.multiply(B).divide(C), casting the multiplication result is useless
since it is not yet the final result).
>
Reification of generics would add some benefit at runtime, it should
>
work say after you call asType() which currently always returns Q, in
>
a future Java version we might get Energy, Mass or Length instead, or
>
Quantity<Energy>. Allowing implementing classes to check operations at
>
runtime primarily. Other than the mentioned type annotations there is
>
no way you could do this at compile time even with what Java may get
>
via "Valhalla" or similar projects.
The fact that there is no way to get compile-time safety for the
multiply operation in current or foreseeable Java was the whole point
against UNITSOFMEASUREMENT-62 since the beginning (together with
"parameterized types shall not lie"). And I agree that reification of
generics will not change anything, since reification is not about
expanding the expressiveness power of Java parameter type syntax.
>
Do you think asType() or whatever we'd call it there, works well in
>
Quantity, too?
I think it should work well. But in my own opinion, letting the user
cast himself the result to a subtype like Energy looks cleaner. I will
try to demonstrate the feasibility on JavaSE 6, 7 and 8 after I start to
work on a RI clone.
Martin