Use Advanced Search to search the entire archive.
Re: Email proposal to the core-libs-dev@openjdk.java.net
- From: Martin Desruisseaux <
>
- To:
- Subject: Re: Email proposal to the
- Date: Tue, 21 Oct 2014 17:11:01 +0900
- Organization: Geomatys
Hello Otávio
Le 21/10/14 04:27, Otávio Gonçalves de Santana a écrit :
>
But Martin, if you don't explain exactly, the help will not valuable.
>
Because our problem happens because the Erasable effect.
The erasable effect is exactly the same with the example that I
provided. This is the exact same thing with only different names (e.g.
Quantity -> Comparable, Length -> Integer, Time -> Short), with some
classes (Integer/Short) instead than interfaces (but it doesn't make any
difference for parameterized types) and a different relationship between
R and (X,Y).
If you can point me to a behavioural difference regarding casting and
parameter types, I will abandon the Comparable example. But for now I
see none. All conclusions done on the Comparable example apply also to
Quantity because all differences between the two examples (name, class
vs interface, multiply(x,y) implementation details) are irrelevant to
our problem.
However I could add a section saying "Some members feel that knowledge
of the actual JSR interfaces may change the perspective", and provide
the speed = length/time example. I'm pretty sure that the answer will be
that it makes no difference.
>
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.
The UNITSOFMEASUREMENT-62 method signatures can not come back: they are
logically wrong. If the JSR group went ahead with UNITSOFMEASUREMENT-62,
I would point that flaw to the JCP and I'm sure that it would cause a
massive amount of "no" votes. This is not a Java language limitation. It
is mathematical (if we accept the "/parameterized types shall not lie/"
rule) - it goes beyond all programming languages.
However a new method signature could be back in a different form if the
Java language was extended in a way allowing us to apply operations on
parameter types beyond the standard "<X extends Y>" and "<X super Y>"
operators. However I'm not aware of any plan in the foreseeable future.
Java generic reification is not about that, so it will not change
anything to the method signature problem. Consequently, if we omit those
method and wait for an improved Java generic systems, we may wait for a
very long time.
>
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.
This is not a problem with type erasure. This is a problem with the
expressiveness power of the Java parameterized type syntax. When generic
types will be reified, the only difference is that the (Quantity<Mass>)
cast will not be unsafe anymore. But the UNITSOFMEASUREMENT-62 method
signature still a big no-no because it still lying, and the user will
still have to cast himself.
Martin