Skip to main content

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

  • From: Otávio Gonçalves de Santana < >
  • To:
  • Subject: Re: Email proposal to the
  • Date: Mon, 20 Oct 2014 17:59:57 -0200

This way, I keep may do cast and I could have the same semantic problem,
but with more code.
Unit<Speed> kmh = (Unit<Speed>)SIPrefix.KILO(SI.METRE).divide(UCUM.HOUR);

Or

Unit<Mass> kmh = (Unit<Mass>)SIPrefix.KILO(SI.METRE).divide(UCUM.HOUR);



On Mon, Oct 20, 2014 at 5:54 PM, Werner Keil 
< >
 wrote:

> We just (semantically and functionally) fixed the method. And there won't
> be a "magic wand" by Java or other way to do this in a future version.
> As Martin explained, and we all (more or less[?]) understand, it is more
> correct to cast or if you want to avoid it apply a method like asType().
> That is perfectly type-safe on both sides.
>
> We don't have it in Quantity, which is why the current state would be like
> this (BMIDemo corrected after #62 was dismissed)
> @SuppressWarnings("unchecked")
> Quantity<Area> squareHeight = (Quantity<Area>) height.multiply(height);
> I agree, the compiler warning when casting to something like
> Quantity<Area> may be a bit odd, thus it is worth considering asType() for
> Quantity, too.
> See Jean-Marie's examples for Unit, I put them into a UnitDemo class
>
> https://github.com/unitsofmeasurement/uom-demos/blob/master/console/ri/src/main/java/tec/uom/demo/UnitDemo.java
> Unit<Speed> kmh =
> SIPrefix.KILO(SI.METRE).divide(UCUM.HOUR).asType(Speed.class);
> // Unit<Speed> kmh2 =
> SIPrefix.KILO(SI.METRE).multiply(UCUM.HOUR).asType(Speed.class);
> Unit<?> kmh3 = SIPrefix.KILO(SI.METRE).multiply(UCUM.HOUR);
> If you comment out the middle one, you'll get the runtime exception
> asType() throws for operations that would cause an irregular dimension
> change. It is not full semantic, but compared to accepting "anything" the
> user wants, this is as good as it gets, hence, if we can add a similar
> method to Quantity we're doing pretty good compared to any unit framework
> in Java and many for other languages[?]
>
> Regards,
> Werner
>
> On Mon, Oct 20, 2014 at 9:27 PM, Otávio Gonçalves de Santana <
>  >
>  wrote:
>
>> But Martin, if you don't explain exactly, the help will not valuable.
>> Because our problem happens because the Erasable effect.
>> Maybe the best strategy would remove temporarily, when when it will fix
>> the method go back or keep the new method signature and when possible take
>> care the semantic.
>>
>>
>> IMHO: In Java API is easier add a method and or create a new
>> implementation take care the type, when the Erasable gonna fix, instead
>> just change a signature.
>>
>> On Mon, Oct 20, 2014 at 12:25 PM, Martin Desruisseaux <
>>
>>  wrote:
>>
>>>  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
>>>
>>>
>>
>>
>> --
>> 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
>>
>>
>


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



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

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
 
 
Close
loading
Please Confirm
Close