Use Advanced Search to search the entire archive.
Re: Remove "generic" multiply/divide operations from Quantity
- From: Jean-Marie Dautelle <
>
- To:
- Subject: Re: Remove "generic" multiply/divide operations from Quantity
- Date: Fri, 17 Oct 2014 21:23:27 +0200
Hi all,
I don't want to reopen a debate you might have closed but reading the
arguments above unless anybody has contradictory arguments (please speak
up). I don't see any good reason to use parameterized functions since they
don't provide any compilation or runtime dimensional checking! I am
therefore 100 % aligned with Martin on this topic.
Cheers,
Jean-Marie.
On Fri, Oct 17, 2014 at 2:53 AM, Martin Desruisseaux <
>
wrote:
>
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
>
>
--
It is not the strongest of the species that survives, nor the most
intelligent. It is the one that is most adaptable to change. - Darwin's
Origin of Species (digest)