Skip to main content

Re: Remove "generic" multiply/divide operations from Quantity

  • From: Werner Keil < >
  • To: " " < >
  • Subject: Re: Remove "generic" multiply/divide operations from Quantity
  • Date: Thu, 16 Oct 2014 19:00:07 +0200

Martin/all,

Am 16.10.2014 17:22 schrieb "Martin Desruisseaux" <
>:
>
> Hello Werner
>
> Thanks for your patience (my email was a bit rude, I apologize for that).
>
> Le 16/10/14 23:52, Werner Keil a écrit :
>
>> "Core OpenJDK" and people involved made quite a few bad decisions, i.E.
forking JSON processing APIs or some of the JSON-P JSR against a qualified
opinion of EG members, so asking them seems to make little sense.
>
> In this case, this is a Java question. I will try to put it simply, with
a distinction between facts and opinion:
>
> FACT: the "non-wildcards" proposal, when applied to the specific case of
the Java language, can not be logically consistent.
> FACT: going ahead despite the logical problem break the integrity of Java
parametric type safety.
> OPINION: The JSR-363 group has no authority for breaking the Java
language that way.
>

I see nothing that would break the Java language in either of the proposed
approaches. I had a long and constructive discussion with Unit "Pope"
Andrew Kennedy at Microsoft about 275 around the time it was stopped. He
said, Java has some limitations that make his or e.g. Fowler's theoretical
and academic works harder to implement in than a few other languages.
Turing wrote purely theoretical papers on Computing (also close to where
Kennedy did btw.;-) which he or others later demonstrated in real systems.
A few aspects of the JVM and type system are about to change. Not always
without breaking existing code despite the higest goal of Java and
Sun/Oracle, backward compatibility.

We must finish 363 before any of Java 9 or Valhalla are in place. It is not
our key target, at least on Java 6 or 7 (ME 8) everything also needs to
work due to Embedded systems not always throwing away an old JVM
(especially not if installed in some remote place with little or no
bandwith;-)

>> I asked potential real world power users about the cast vs. an asType()
or multiply(Quantity, Class) alternative and they said, they would prefer
"wildcard".
>
> Okay, we have 4 choices:
>
> User cast to e.g. Energy - relatively simple for the user and safe.
> User cast to e.g. Quantity<Energy> - slightly less simple than 1 and
unsafe.
> Quantity.asType(Class) - less convenient than cast.
> multiply(Quantity, Class) - no advantage over #3.
>
> If we agree to eliminate #3 and #4, choice #1 is the only clean and safe
choice.
>

I must disagree on that. The generic factory approach is incompatible with
#1. And you only could get:
Energy e = someStrictlyTypedThing.multiply()
If you define every single concrete class like EnergyAmount to be final and
implement Energy
(see the SI module or aspects of UOMo)

asType() has turned out to be unstable and cumbersome, so even in Unit it
makes almost no sense at least under the new type system built from SE 8 on.

There are many bugs filed around it, but the general OpenJDK route seems to
take most as "collateral damage". Valhalla aside from value objects also
proposes other changes to the Java type system. A glimpse made it into SE
8, e.g. JEPs like http://openjdk.java.net/jeps/101

Note, Otavio's suggestion goes pretty much in that direction[?]

It does not seem fully integrated with SE 8, see
http://blog.jooq.org/2013/11/25/a-lesser-known-java-8-feature-generalized-target-type-inference/
and the "last updated" date of that JEP long after SE 8 was GA.

It is quite possible, if JEP101 was added to SE 8u20 or other updates, that
some of the incompatibilities arise from that.

Including the problems with asType().

>
>> Given you can have Thpusands of possible return types, an operation that
only returned Energy or BMI (forcing users to declare these Thousands of
interfaces;-O) is unacceptable, not just to them.
>
> I do not understand your objection.
>
> Interfaces are provided by JSR-363, not by the user (except their custom
ones). Why would they need to declare them?
> Where to you see thousands of interfaces? There is about 50 of them.
> Maybe you mean "forcing user to implements these 50 interfaces"? If so, I
remind for the 4th time that they do not need so on JavaSE, thanks to
java.lang.reflect.Proxy, and JavaME are expected to include only a subset.
> Or maybe you means "thousands of methods", not interfaces? Nobody is
suggesting to do that. The only method that we need is:
>>
>> Quantity<?> multiply(Quantity<?> other);


I'm not talking abot the 50 or so interfaces in the API or SI module, it's
all the possible variations, be it "Weight loss over time and distance",
"BMI", "CO² footprint", etc.

If API insisted on a type like "Energy", then for each possible return type
an interface and implementing class had to be declared, otherwise you
simply cannot do the calculation, or have to use tricks like definig a type
like "Any". Which worked for implementing solutions anyway if they wanted,
hence makes many aims of this discussion redundant.

Both the  Quantity<T> return type and a Quantity<?> one are flexible, not
forcing developers to declare an interface for every single final or
intermediary value they need for their calculations.


>
> This is the only method that we can provide. Yes, it forces user to cast.
But we have no other choices except breaking Java integrity, defining
thousands of methods or polluting the API with Class argument.
>
>

Otavio also mentioned, Lambda related JEPs including 101 could be broken or
made extremely hard to cope with by the existing <?> approach.


Could we focus on that if possible?[?]


While aiming to remain backward-compatible for the time being at least with
SE 6 or 7 (and ME 8 of course) type changes by those who really change and
evolve the Java language (not us, at the moment we USE those, but do not
cater to the platform with v 1.0 of this JSR[?]) must also work without
breaking implementations of the API.


Werner


>> It looks inevitable some or most implementations would also accept
quantities, if we simply deprived the API from them, then we pave the field
for a "schism" or "diversified approach" whatever you like to call it;-)
>
> Which deprived API are we talking about? I'm not suggesting to remove
multiply. I'm suggesting to revert to a method signature that does not
break Java type-safety. The old method signature was in my opinion the best
we can achieve.
>
>     Martin
>

Attachment: 329.gif
Description: GIF image

Attachment: 347.gif
Description: GIF image



Re: Remove "generic" multiply/divide operations from Quantity

(continued)

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/01/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/01/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/01/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/12/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/13/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Leonardo Lima 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Jean-Marie Dautelle 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/16/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/17/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/17/2014
 
 
Close
loading
Please Confirm
Close