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

