Use Advanced Search to search the entire archive.
Re: Email proposal to the core-libs-dev@openjdk.java.net
- From: Werner Keil <
>
- To: "
" <
>
- Subject: Re: Email proposal to the
- Date: Mon, 20 Oct 2014 13:08:51 +0200
Martin,
Thanks for the reply. And confirming, you prefer to keep <?> methods in the
API.
Other downstream users are likely to use methods in Quantity, and the
ideological or "aestaetical" issues, Otavio mentioned affect Unit even more
than Quantity, so changing or removing any should consequently affect all
if anybody really wanted to do that.
I am pretty sure, a semantic connection between input and output will never
be available in Java. Some hard-wired hack and workaround like JSR 308
style type annotations are available but nobody really uses them. See the
"Checker Framework" its Unit support is cumbersome and totally incomplete,
plus it also only works at compile time and the information is not
available at runtime (can't say if there is some way to access them via
Reflection or not)
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.
I don''t think bothering the JDK team at the moment makes sense. There
could be some kind of review during JSR stages, and if they are interested
or have something to add, they'll do, but again, this JSR is not aiming at
the platform in its 1.0 release at all, hence they normally have other
things to worry about[?]
Offering a "module" at a later stage could be possible, but let's see, how
it goes with Jigsaw first, that was due for many years, so we have to see
it work in Java 9 hopefully[?]
Otavio's input was neverthless valuable, especially as a remedy for issues
around asType(). the most type safe alternative to a cast or the <?>
wildcard for these operations.
Do you think asType() or whatever we'd call it there, works well in
Quantity, too? I am not sure, if simply routing everything to the
underlying Unit is sufficient, I believe in classes like AbstractQuantity I
even got that method already. Would be consequent to make it available in
the API.
Via the NumberValue wrapper around Number in JSR 354 there are methods
similar to asType() but for picking a particular number class like Double,
BigDecimal, etc.
At least to retrieve the factory, MonetaryAmount also returns a <?>
wildcard btw.[?] The fact it extends a type does not matter, the <?>
wildcard in Quantity or Unit is always restricted to match what <Q> does.
so you can never use Quantity<String> or Quantity<Object> but only
something like Quantity<Length>[?]
Regards,
Werner
On Mon, Oct 20, 2014 at 5:13 AM, Martin Desruisseaux <
>
wrote:
>
Le 20/10/14 09:04, Werner Keil a écrit :
>
> Please especially Martin/Jean-Marie, would you be happy to "split" the
>
> API?
>
Could you elaborate about what you mean by "split"?
>
>
> Both on Quantity AND Unit of course, because the "crux" meaning all
>
> <?> methods, Otavio feels are inappropriate result from Unit;-)
>
>
>
It depends if we envision any extension to the Java parameterized type
>
system in the foreseeable future which would allow us to express the
>
relationship between input and output arguments.
>
>
> Now what about removing every <?> method:
>
> divide() and multiply(<?>) invert() and potentially pow() from both
>
> Quantity and Unit?
>
I'm neutral about Quantity operations (as long as, if present, they are
>
semantically corrects), since we never use them. But removing those
>
operations from Unit would cause me to abandon JSR-363.
>
>
Martin
>
>
Attachment:
329.gif
Description: GIF image
Attachment:
347.gif
Description: GIF image