Skip to main content

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

  • From: Werner Keil < >
  • To:
  • Subject: Re: Remove "generic" multiply/divide operations from Quantity
  • Date: Thu, 16 Oct 2014 16:52:13 +0200

AFAIK Otavio does contribute to OpenJDK, while this has no relevance to
them or the team as of now;-)

"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.

I just attended a CoAP related IoT MeetUp in Vienna and all stakeholders
and interest groups hoping to cash in on IoT seriously lack proper
standards in this area. This may only be for Java, though via UCUM, JSON,
or other textual formats it is open to other languages, not to mention
Groovy, Scala,... also benefiting from it.

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". 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.
Just have a look at API "test" classes, you can always do that and
ultimately declare strictly typed math like:
Volume = Area.multiply(Area)
In addition to implementing the generic ones.

We shall explain and document this alrernative in the Spec. Look at it
somewhat similar to all the concrete subtypes and implementations, JSR 310
threw into Java 8. They stick there and bloat Java even beyond Jigsaw,
making it useless to ME where the initial Date/Calendar framework is the
only alternative. Another blunt failure where neither "Core JDK" nor ME
savy experts who were involved could help the Spec Lead being practically a
1-man EG. Take Temporal* you nevertheless have a "low level" API and
"Miniature Spec". It claims "Don't use it" but nobody can keep developers
from using TemporalAmount or *Unit or even create their own
implementations;-)

Our Quantity and Unit has more power and purpose. Only restricting add(),
multiply()... to concrete types like JSR 310 (or our prior API;-) might be
an option, but I feel it would deprive developers and users from a lot of
value.

Think of what you want. The operation-less version is what we got in 0.6
leaving it up to every implementation to do that. JSR 354 got even more
operations btw, but Money has more specific needs.
This blog picked up Fowler's ideas and discusses them further:
http://www.step-10.com/SoftwareDesign/General/QuanitiesAndUnitsOfMeasure.html

He would prefer to only do multiply and divide with numbers.
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;-)

One may not do:
Quantity.multiply(Quantity)
But depending on implementations has to do:
SEQuantity.multiply(Quantity)
or
SEQuantity.multiply(SEQuantity)
via an assumed (SE) implementation.

Whether or not this is available on ME, JScience, etc. would be entirely up
to each implementation.
RI naturally won't!
We're not obliged to do anything that API doesn't specify;-)

WDYT?
 Am 16.10.2014 08:53 schrieb "Martin Desruisseaux" <
>:

>  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
>
>
>

Attachment: 329.gif
Description: GIF image

Attachment: 330.gif
Description: 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

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

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

Jean-Marie Dautelle 10/16/2014

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

Otávio Gonçalves de Santana 10/16/2014
 
 
Close
loading
Please Confirm
Close