Use Advanced Search to search the entire archive.
Re: Remove "generic" multiply/divide operations from Quantity
- From: Martin Desruisseaux <
>
- To:
- Subject: Re: Remove "generic" multiply/divide operations from Quantity
- Date: Fri, 17 Oct 2014 00:22:00 +0900
- Organization: Geomatys
Hello Werner
Thanks for your patience (my email was a bit rude, I apologize for that).
Le 16/10/14 23:52, Werner Keil a écrit :
>
"Core OpenJDK" and people involved made quite a few bad decisions,
>
i.E. forking JSON processing APIs or some of the JSON-P JSR against a
>
qualified opinion of EG members, so asking them seems to make little
>
sense.
In this case, this is a Java question. I will try to put it simply, with
a distinction between facts and opinion:
1. *FACT:* the "non-wildcards" proposal, when applied to the specific
case of the Java language, can not be logically consistent.
2. *FACT:* going ahead despite the logical problem break the integrity
of Java parametric type safety.
3. *OPINION:* The JSR-363 group has no authority for breaking the Java
language that way.
>
I asked potential real world power users about the cast vs. an
>
asType() or multiply(Quantity, Class) alternative and they said, they
>
would prefer "wildcard".
Okay, we have 4 choices:
1. User cast to e.g. Energy - relatively simple for the user and safe.
2. User cast to e.g. Quantity<Energy> - slightly less simple than 1 and
unsafe.
3. Quantity.asType(Class) - less convenient than cast.
4. multiply(Quantity, Class) - no advantage over #3.
If we agree to eliminate #3 and #4, choice #1 is the only clean and safe
choice.
>
Given you can have Thpusands of possible return types, an operation
>
that only returned Energy or BMI (forcing users to declare these
>
Thousands of interfaces;-O) is unacceptable, not just to them.
I do not understand your objection.
* Interfaces are provided by JSR-363, not by the user (except their
custom ones). Why would they need to declare them?
* Where to you see thousands of interfaces? There is about 50 of them.
* Maybe you mean "/forcing user to implements //these 50 interfaces/"?
If so, I remind for the 4th time that they do not need so on JavaSE,
thanks to java.lang.reflect.Proxy, and JavaME are expected to
include only a subset.
* Or maybe you means "/thousands of methods/", not interfaces? Nobody
is suggesting to do that. The only method that we need is:
Quantity<?> multiply(Quantity<?> other);
This is the only method that we can provide. Yes, it forces user to
cast. But we have no other choices except breaking Java integrity,
defining thousands of methods or polluting the API with Class argument.
>
It looks inevitable some or most implementations would also accept
>
quantities, if we simply deprived the API from them, then we pave the
>
field for a "schism" or "diversified approach" whatever you like to
>
call it;-)
Which deprived API are we talking about? I'm not suggesting to remove
multiply. I'm suggesting to revert to a method signature that does not
break Java type-safety. The old method signature was in my opinion the
best we can achieve.
Martin