Use Advanced Search to search the entire archive.
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