Use Advanced Search to search the entire archive.
Re: Remove "generic" multiply/divide operations from Quantity
- From: Martin Desruisseaux <
>
- To:
- Subject: Re: Remove "generic" multiply/divide operations from Quantity
- Date: Fri, 17 Oct 2014 09:53:26 +0900
- Organization: Geomatys
Hello Jean-Marie
Le 17/10/14 06:49, Jean-Marie Dautelle a écrit :
>
Werner or Martin could you pose the question in simple terms that we
>
can all answer by yes or no.
Some are proposing to change the signature of:
Quantity<?> multiply(Quantity<?> that)
to (note that this signature express no relationship between T and R):
<T extends Quantity<T>,R extends Quantity<R>> Quantity<R>
multiply(Quantity<T> that)
(and similarly for divide, pow, etc.) in order to allow the following to
compile without the need to cast:
Quantity<Length> length = ...;
Quantity<Time> time = ...;
Quantity<Speed> speed = length.divide(time);
But this cause the compiler to also accept:
Quantity<Mass> mass = length.divide(time);
Quantity<Volume> volume = length.divide(time);
Quantity<Force> force = length.divide(time);
// Anything...
The proposed method does not express any real relationship between the
quantity types, since the type result of a multiplication is impossible
to express in Java. It is also impossible to implement without "/unsafe
cast/" warnings on the implementation side that can be proved to be
safe. The sole purpose of the proposed method is to trick the compiler
for automatically perform *unsafe* cast without warning on the user
side. It is equivalent to writing a method foo() in such a way that:
List<String> list = foo();
can actually assign to list instances of List<Integer>, or List<Date>,
or anything else, without any compiler warning. Argument of promoters of
this approach is "the developer should know what he is doing". My
argument is: it break the whole purpose of parameterized type (bring us
back to the same level of safety as non-existence of parameterized
types). Worst: it gives to developer a false feeling of safety. Normally
if an expression like:
Quantity<Mass> mass = ...,
compiled without compiler error or warnings, then the developer is
confident that mass is really a mass or null. The proposed change breaks
that confidence: mass could actually be a volume without any warning. I
also argue that my worry goes beyond JSR-363 scope: if libraries starts
to do that, it breaks the confidence that developers can have in Java
parameterized type in general. For this reason I'm 100% sure that this
proposal will be considered unacceptable by the JCP or any OpenJDK folk.
Martin