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 13:33:45 +0200
Otavio/all,
As Martin mentioned, Generic type safety while being flexible to allow any
operation on either Unit or Quantity with different arguments (not
hard-wired Length.multiply(Length) accepting only that with Area as result,
that would be type safe, implementations may use it, but it is not very
flexible for creating formulas for different calculations) was added first
with JSR-275 thanks to mainly Jean-Marie's input.
Note, none of the default Quantity types are "implementation", they extend
the API interface also in the same API, that is part of the API, not
imlementation.
*Implementation *if you chose a concrete type would be:
*class LengthQuantity implements Quantity, Length *
(or extending say BaseQuantity)
It is neither possible nor desired to create a strict "harness" that would
never allow "kg/h" but only "km/h", just because only the latter is based
on another SI quantity (Speed)
For a fitness app similar to the BMI I already used in other examples
"kg/h" as some "Workout Factor" is just as legitimate and possible as
"km/h".
So there is no way to say upfront that
Quantity<Mass> mass;
Quantity<Time> time;
Quantity<?> workoutFactor = mass.divide(time);
is not correct, for some use cases it is.
(or if you insist to add a custom interface asType(WorkoutFactor))
Blocking some use cases would practically mean a "Field of Use Restriction"
and while Oracle or other JSRs may have that from a license point I see
absolutely no reason to do that here. If applications wish to further
restrict the possible operations, they may need to look into JSR 308.
Unless it also works for complex types like Quantity, it seems useless to
our implementations, but you are welcome to explore it, that is the only
way you could restrict the outcome at compile time.
JDK addition is totaly out of discussion, we went there (Martin,
Jean-Marie, you know) and it was among reasons some EC members turned it
down. Not for all, but for some, so similar to JSR 354 (which via Currency
has far more motivation to offer that even in Java 9 if they want and JDK
does, too?) this is a STANDALONE JSR and not even offering platform
inclusion right now. A "profile" on top of Java ME (8 or 9) and MEEP is
whare we aim if anything. For SE post JDK 9 the platform could "invite" it,
if there is user demand, e.g. in Embedded, but once some sort of Module is
also available to things outside the JDK, adding modules breaks the
monolithic "JDK pre-installed" schema, and those who need units in their
app will use it, regardless if it's a "core module" or not. This makes it
flexible, not dependent on too many other things and small, unlike some of
the monolthic pseudo JSRs you find in Java 8 that are hard to get rid even
with Jigsaw[?]
So let's please worry about things like getting formatting right, that is
far more important for users to accept it or not. Otherwise not even as
standalone it would seem useful to many.
Cheers,
Werner
On Mon, Oct 20, 2014 at 1:08 PM, Otávio Gonçalves de Santana <
>
wrote:
>
>
Hello all
>
>
My apologize for resorting to this mailing list for a question about an
>
external API. I'm doing that, with agreement from other members of the JSR
>
group, for a JSR which could possibly be proposed for inclusion in the JDK
>
in some future version. I'm seeking confirmation about whether the
>
following rule shall suffers no exception. In a nutshell (more detailed
>
explanation below), given the following method signature where X, Y and Z
>
are the same interfaces:
>
>
X<Y> foo();
>
>
I claim that it would be unacceptable to have the foo() method
>
implementation actually returning instances of X<Z> through parameterized
>
type erasure (ignoring cases like Collections.emptyFoo() where object
>
properties do not depend on the parameter type). I claim that no "developer
>
convenience" consideration can justify such breaking of Java parameter type
>
safety. Some other peoples have the point of view that the developer should
>
know what he is doing.
>
Details
>
Given:
>
>
public interface Quantity<Q extends Quantity<Q>> {
>
}
>
>
>
We have some implementations:
>
>
public interface Mass extends Quantity<Mass> { }
>
>
public interface Length extends Quantity<Length> {
>
}
>
>
public interface Speed extends Quantity<Speed> { }
>
>
>
public interface Time extends Quantity<Time> { }
>
>
In this discussion I use the standard Quantity<?> interface and its Time
>
and Speed implementations for familiarity, but the actual JSR objects
>
are semantic different. Consider the following method:
>
>
Quantity<?> multiply(Quantity<?> that);
>
>
>
Some peoples in our JSR group feel very strongly against the <?> wildcard
>
in return value. They consider it as a sign of bad design (note that I
>
disagree - for me in this particular situation, it means "can not be
>
expressed by the current Java parameterized type syntax". A JDK example of
>
such case is Class.getEnclosingClass()). Some peoples are pushing for the
>
following method declaration:
>
>
<T extends Quantity<T>, R extends Quantity<R>> Quantity<R>
>
multiply(Quantity<T> that);
>
>
>
Doing this:
>
>
Quantity<Length > x = ...;
>
Quantity<Time> y = ...;
>
Quantity<Speed> r = x.multiply(y);
>
>
>
But can happen semantic problems like this:
>
>
>
Quantity<Speed> x = ...;
>
Quantity<Time> y = ...;
>
Quantity<Mass> r = x.multiply(y); // is the same interface, but the
>
semantic is wrong, because multiply speed to time does not result in Mass.
>
>
...
>
>
>
>
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:*
>
>
>
>
On Mon, Oct 20, 2014 at 12:33 AM, Martin Desruisseaux <
>
>
>
wrote:
>
>
> Le 20/10/14 05:35, Otávio Gonçalves de Santana a écrit :
>
> >
>
> > Martin, please try explain more uor case.
>
> > We are using the same interface, or use the Number instead long or
>
> > double.
>
> >
>
> I'm not sure to understand what you mean. By "we are using the same
>
> interface", you mean to emphases that Short and Integer (or Long or
>
> Double) are sub-types of Comparable, like Length and Mass are subtypes
>
> of Quantity? We can, but what does it change to the point?
>
>
>
> 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:
329.gif
Description: GIF image