Skip to main content

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

GIF image

GIF image



Re: Remove "generic" multiply/divide operations from Quantity

(continued)

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/01/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/01/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/01/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/01/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/01/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/01/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/01/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/12/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/13/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Leonardo Lima 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/16/2014
 
 
Close
loading
Please Confirm
Close