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: Tue, 21 Oct 2014 08:12:48 -0200
Martin, in your example can happen ClassCastException, in our case not,
because we are using the same interface.
I did a brief of the code below, I am just using Generics with diamond
resources, available in Java 7 or above. Can you show me how may happen the
same thing with this code or the cast could be unsafe?
I believe our problem is about semantic and you would be cool say our
scenario.
public interface Quantity<Q extends Quantity<Q>> {
<T extends Quantity<T>, E extends Quantity<E>> Quantity<E>
multiply(Quantity<T> that);
}
public interface Mass extends Quantity<Mass> {
}
public interface Speed extends Quantity<Speed> {
}
public interface Length extends Quantity<Length>{
}
public class BigDecimalQuanity<Q extends Quantity<Q>> implements
Quantity<Q> {
public <T extends Quantity<T>, E extends Quantity<E>> Quantity<E>
multiply(Quantity<T> that) {
return new BigDecimalQuanity<>();
}
}
On Tue, Oct 21, 2014 at 6:11 AM, Martin Desruisseaux <
>
wrote:
>
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
>
>
--
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