Skip to main content

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

  • From: Werner Keil < >
  • To: " " < >
  • Subject: Re: Email proposal to the
  • Date: Mon, 20 Oct 2014 22:05:05 +0200

That's why asType() is necessary also for Quantity

Unit<Mass> kmh4 =
SIPrefix.KILO(SI.METRE).multiply(UCUM.HOUR).asType(Mass.class);
throws
Exception in thread "main" java.lang.ClassCastException: The unit: h·km is
not compatible with quantities of type interface javax.measure.quantity.Mass
at tec.uom.se.AbstractUnit.asType(AbstractUnit.java:252)
at tec.uom.se.AbstractUnit.asType(AbstractUnit.java:60)
at tec.uom.demo.se.UnitDemo.main(UnitDemo.java:16)
and there is no cast required.

Problem solved[?]

On Mon, Oct 20, 2014 at 9:59 PM, Otávio Gonçalves de Santana <
>
 wrote:

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

Attachment: 35F.gif
Description: GIF image

Attachment: 330.gif
Description: GIF image

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

Re: Email proposal to the

Martin Desruisseaux 10/21/2014
 
 
Close
loading
Please Confirm
Close