Skip to main content

Re: Email proposal to the core-libs-dev@openjdk.java.net

  • From: Martin Desruisseaux < >
  • To:
  • Subject: Re: Email proposal to the
  • Date: Mon, 20 Oct 2014 23:25:22 +0900
  • Organization: Geomatys

Thanks Otávio for the proposed updated email. On usage of Quantity
versus Comparable in the code examples, I took Comparable because it
reproduces the same problem without requiring the reader to learn new
types. The Quantity interfaces are only distraction for this issue -
they do not add anything relevant to the problem, since the same
mechanism play in both examples. Or if I missed something, please point
to me which parameterized types behaviour would be different if we
replace Comparable by Quantity.

This is like bug reports: simpler is the test case that reproduce the
problem, the more likely it will be taken in consideration. However I
could add the Quantity example in a kind of short annex in case someone
wants to see the actual types.



Le 20/10/14 20:08, Otávio Gonçalves de Santana a écrit :
> I don't understand this point, how not subtype, the multiplier can of
> Quantity can result a Unit or just Quantity?, I believe our problem is
> about semantic no?
> _Let assume that the type of the return value is not necessarily the
> type, or a subtype, or a super-type of any of the arguments. It may be
> for example because the multiply method applies the Java rules of
> Binary Numeric Promotion (JLS §5.6.2). Consequently, the return type
> use the <?> wildcard since we can not express the actual return type
> as a function of X and Y with the parameterized type syntax. This
> force the users to cast as in the following example:_

The above sentence is unrelated to Quantity. For my example with
Comparable, I needed an operation in which the return type R can not be
expressed as a function of input types (X, Y). I wanted an operation
that readers know, because I want to clear from this email any new
concepts that are not necessary for the description of the problem. So I
pickup the Java Binary Numeric Promotion rules: float*double= double; 
int*long = long;  short*short = int, etc. The OpenJDK readers know well
those rules. Introducing new rules like Speed= Length/Time, even if we
can assume that most peoples know them (but they are not familiar with
how we express them in Java), brings nothing to the description of the
problem. But we could put them in the above-cited proposed annex.

The UNITSOFMEASUREMENT-62 issue is a Java language problem, not an
expert domain problem. This is why I try to express it only in terms of
standard Java elements.

    Martin



Email proposal to the

Martin Desruisseaux 10/19/2014

Re: Email proposal to the

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

Re: Email proposal to the

Martin Desruisseaux 10/20/2014

Re: Email proposal to the

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

Re: Email proposal to the

Werner Keil 10/20/2014

Re: Email proposal to the

Martin Desruisseaux 10/20/2014

Re: Email proposal to the

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

Re: Email proposal to the

Werner Keil 10/20/2014

Re: Email proposal to the

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

Re: Email proposal to the

Werner Keil 10/20/2014

Re: Email proposal to the

Martin Desruisseaux 10/21/2014

Re: Email proposal to the

Martin Desruisseaux 10/21/2014

Re: Email proposal to the

Werner Keil 10/21/2014

Re: Email proposal to the

Martin Desruisseaux 10/21/2014

Re: Email proposal to the

Werner Keil 10/21/2014

Re: Email proposal to the

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