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 21:54:15 +0200
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
>
>
Attachment:
35F.gif
Description: GIF image
Attachment:
347.gif
Description: GIF image