Use Advanced Search to search the entire archive.
Re: Remove "generic" multiply/divide operations from Quantity
- From: Otávio Gonçalves de Santana <
>
- To:
- Subject: Re: Remove "generic" multiply/divide operations from Quantity
- Date: Thu, 16 Oct 2014 06:43:09 -0300
Martin.
How I told in Jira[1], it's not more a technical discussion.
If we take care of the operations ,division/multyply, you are right if not
just believe in user will another strategy.
[1]
https://java.net/jira/browse/UNITSOFMEASUREMENT-62#comment-381041
On Thu, Oct 16, 2014 at 3:53 AM, Martin Desruisseaux <
>
wrote:
>
Hello all
>
>
I feel hesitation in participating to this doodle, since it seems a
>
non-sense to me. It is not a matter of democracy or opinion. The proposed
>
non-wildcards signature is a violation of the laws of logic. To me, this
>
pool is like asking "*would you like 2+2 to be equal to 4 or to something
>
else?*" and praising the virtue of democracy in answering that question.
>
Even if thousands of "domain experts" vote for 2+2=5, it is still wrong.
>
>
Java parameterized type syntax is a kind of mathematical function that
>
establish a mapping between class type, method argument type and return
>
type. The universe of possible relationships is practically infinite, but
>
Java syntax can express only the following:
>
>
- Same type
>
- Subtype
>
- Super-type
>
>
Any other kind of relationship can not be expressed in Java. Note that
>
this is a limitation of the Java language, not a logical restriction, as
>
other languages have more capabilities. For example C++ templates allow
>
arithmetic operations on parameterized types (a "type" in C++ can be a
>
compile-time numerical value). With C++ capabilities, Otavio's wish could
>
be fulfilled (see Barton J. & al., 1994, *Scientific and Engineering C++*,
>
Addison-Wesley - they have done exactly that 20 years ago).
>
>
Given the above Java limitation, *no matter how we turn the problem
>
around, there is absolutely no way to express the type result of an
>
arithmetic operation in the Java language.* It is simply impossible,
>
because the relationship between input and output types is not one of the
>
above-cited supported relationships. *Werner, can you understand that
>
this is logic, not opinion?*
>
>
What Otavio wants to do has been solved at least 20 years ago. But it
>
requires arithmetic operations on parameterized types, which is possible in
>
C++ but not in Java. Consequently, in our case the <?> wildcard does not
>
mean "bad design". It means "*result is outside the scope of what we can
>
express in Java*".
>
>
Bloch"s "Effective Java" book said (emphasis is mine):
>
>
Eliminate every unchecked warnings that you can. (...) If the warning
>
cannot be eliminated, *and you can prove the code is safe*, then you can
>
use a @SuppressWarnings("unchecked") annotation to eliminate the warning.
>
When using @SuppressWarnings("unchecked") annotation, *you must comment
>
why it is correct and safe*.
>
>
We can not prove that the multiply, divide, inverse and pow code are safe
>
in current Java - as explained above, it is impossible. Consequently we
>
shall not suppress the warnings. The only clean way to suppress the
>
warnings is to cast to e.g. Energy instead than Quantity<Energy> in user
>
code. This is the only safe path I can see (except asType(Class)). If
>
such casting is still considered too annoying, then we could consider
>
removing completely parameterized type, so casting would not be needed
>
anymore. Indeed, the UNITSOFMEASUREMENT-62 proposal is a complicated way to
>
said "*behave here as if parameterized type did not existed*". It does
>
*not* express the real relationship between argument and return type, and
>
is *logically impossible* to implement safely in Java.
>
>
I can not understand why some developers stay blind in front of the law of
>
logic. Again, I'm not pushing for my own opinion - I'm trying to explain
>
that 2+2=4 and that we can not accept to said "*oh well, let accept 2+2=5
>
or 6 or 7 here for the sake of convenience*". I feel so desperate that
>
I'm considering to send email to
>
>
asking
>
for rescue, since they were some talk about possible inclusion of JSR-363
>
in the JDK. I have no doubt that many would be horrified by the idea of
>
"lying parameterized types".
>
>
Martin
>
>
>
Le 14/10/14 06:59, Werner Keil a écrit :
>
>
All,
>
>
I sent a doodle out to ever EG member (by name, not to the list, as it
>
would not go through)
>
Only one choice per participant is allowed, that makes sense here, since
>
it is pretty much a
>
"Cast and wildcard vs. non-wildcard Generic" (of course users can also
>
pass the result into a "wildcard" variable or use it as argument as long as
>
it involves Quantity)
>
>
Please submit your choice, then we know who has what preference. If
>
feasable (after next Mon evening I should be in a hotel again with Wifi,
>
hopefully stable to join Hangout, Skype, etc.) we could have a more
>
detailed discussion, but so far it is important that every EG member who
>
has an opinion declares it here. Not just Otavio and Martin (with
>
occasional input by Leo or me[?]) Everyone including Spec Leads should
>
vote. If necessary and all 3 Spec Leads participate, 2 out of 3 would be a
>
majority in the end[?] Spec Leads ultimately shall decide, in some cases
>
and other JSRs they rarely care to ask others, here we try to work
>
transparent and democratic.
>
>
And during recent F2F e.g. Heather also noted activity like this on the
>
mailing lists as positive[?]
>
>
Regards,
>
Werner
>
>
>
--
Otávio Gonçalves de Santana
blog:
http://otaviosantana.blogspot.com.br/
twitter:
http://twitter.com/otaviojava
site: *
http://about.me/otaviojava <
http://about.me/otaviojava>*
55 (11) 98255-3513

