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 22:11:30 +0200

I left that conclusion ("pruning" of some methods or at least leaving them
to implementations like UOMo or JScience did previously) as a possible
option.
It could be a little inconsistent as to where to apply them. If you had a
Quantity type at least you'd need to cast it to SEQuantity (assuming that
type exists in an SE specific implementation) or do all of your operations
 with SEQuantity<Q> after all. There both
multiply(Number) and
multiply(SEQuantity) or multiply(Quantity) could still exist.

I'll try to phrase a quick question to the interested parties at Eclipse
IoT. So far they said they prefer to stay without explicit classes, their
response also was against a
R multiply(Quantity<T>) because there are so many possible return types.

About Martin's question, I can only give one example, but there are at
least 50-70 cases in UCUM alone where asType() broke in JDK 8u20 and above.
POUND_FORCE was
Unit<Force> POUND_FORCE =
addUnit(POUND.multiply(ACCELLERATION_OF_FREEFALL).asType(Force.class));
but had to become
Unit<Force> POUND_FORCE = addUnit(new ProductUnit<Force>(
POUND.multiply(ACCELLERATION_OF_FREEFALL)));

otherwise the SE port did not compile there any more

Thanks,
Werner

On Thu, Oct 16, 2014 at 9:46 PM, Leonardo Lima 
< >
 wrote:

> Hello all.
>
> As Werner mentioned, I "abstained" from the voting because I understand
> (as Otavio also pointed) that this is a more wide problem than our use
> cases. API design is not my forte, I'll admit, but I'm keeping up with the
> discussion.
>
> Still, I think it's valid that Martin (or Otavio or even I) write to
> OpenJDK and ask about this, specially considering that we would like to be
> part of the standard platform. I don't think this would bring bad
> impression, au contraire, it should show that we care about what we're
> doing specially outside our clique.
>
> In the end, I understood that:
>
>    1. What I (really) wanted can't be achieved without "exploding" the
>    JSR to have bajilion methods. That's not feasible.
>    2. The convenient way to achieve somewhat what I wanted (the signature
>    that sparked this thread) breaks Java rules of generics expectations.
>    That's Martin's main point.
>    3. The best way to continue with Generics is using the <?> and then
>    force the API user to cast.
>       1. But, then, why not drop it from the signature?
>       2. And add signature in JSR 363.1 when better support is available
>       in the language?
>
> Regards,
> Leonardo.
>
> On Thu, Oct 16, 2014 at 4:42 PM, Otávio Gonçalves de Santana <
>  >
>  wrote:
>
>> Martin, did you send the email?
>> Please go a head.
>>  Le 17/10/14 02:54, Werner Keil a écrit :
>>
>>  Do what you cannot leave, but note, unless either of the Spec Leads
>> (Leonardo abstained from the ballot till he gets a better idea of the
>> subject/discussion, Jean-Marie has been silent on all of it, maybe he is
>> busy or has no opinion?) sanction that, it makes a bad impression of the
>> work of the EG[?]
>>
>> I know it will make a bad impression. But frankly, if this group can not
>> perform a logical analysis, we deserve it.
>>
>>
>>   We try to be as democratic as possible
>>
>> But main parts of my argument is about *logic*! Democracy has nothing to
>> do in logic. Do you think that expressions like "*if A=B and B=C then
>> A=C*" is a matter of opinion? On which of the following points do you
>> disagree? (I explained those points in more details in my first today's
>> email):
>>
>>
>>    1. *LOGICAL FACT:* the "non-wildcards" proposal, when applied to the
>>    specific case of the Java language, can not be logically consistent.
>>    2. *LOGICAL FACT:* going ahead despite the logical problem break the
>>    integrity of Java parametric type safety.
>>    3. *OPINION:* The JSR-363 group has no authority for breaking the
>>    Java language that way.
>>
>>
>> If I'm wrong on point 1 or 2, it should take you only 5 minutes to
>> convince me: just point to the logical flaw in the arguments of my first
>> today's email.
>>
>>
>>   Otavio changed the Dynamic Proxy version using Reflection in the SE
>> port. And given there is no Reflection in ME 8, most of it also got applied
>> to RI.
>>
>> Do we agree that SE can use reflection, and that ME take only a subset of
>> quantity types?
>>
>>
>>   The only place you may refer to is the old JSR 275 code as there was
>> no other QuantityFactory in the later API:
>>
>https://kenai.com/projects/jsr-275/sources/svn-repository/content/trunk/jsr-275/src/main/java/javax/measure/quantity/QuantityFactory.java?rev=259
>>
>> Yes I was thinking about that class. It could be simplified a little bit.
>>
>>
>>   It returned the interface, but that at the time was "crippled", the
>> Quantity had no operations.
>>
>> We can add the operations, no problem with that.
>>
>>
>>    And see JScience 4.x (intended as RI of JSR 275) that took Quantity
>> and returned Quantity<?> or Quantity<Q> for all relevant operations, not Q
>> [?]
>>
>> But nobody proposed to return Q! I explicitly wrote *Quantity<?>
>> multiply(Quantity<?>)* in my previous email! I also wrote "*the old
>> method signature was in my opinion the best we can achieve*". Energy is
>> a subtype of Quantity<Energy>, which is itself assignable to Quantity<?>.
>> Consequently a Quantity<?> multiply(Quantity<?>) method can return an
>> instance of Energy. No need for thousands of methods or methods
>> returning Q.
>>
>>
>>   We cannot do a "diff" between all unit systems, especially US or UCUM
>> here, but if you do that diff, you'll see all the places that asType()
>> simply broke the code starting with SE 8u20. Also look at SE port issues,
>> especially all
>https://github.com/unitsofmeasurement/unit-impl-se/issues?q=is%3Aissue+is%3Aclosed
>>
>> I found no mention of 'asType' under that link and by browsing in the
>> comments, but maybe I didn't looked hard enough. Anyway this is not the
>> main issue, since we are not proposing a Quantity.asType(Class) method.
>>
>>
>>   Including the problems with asType().
>>>
>>>   I'm sure that this problem does not exist.
>>>
>>
>>  It does, see above, in the SE 8 implementation there are very few cases
>> where asType() did not break the code and it seems the remedy could be used
>> to replace all existing calls.
>>
>> Then, please point me to a place where it broke the code. Is it possible
>> to give me something more accurate than digging in the history of the
>> entire project?
>>
>>     Martin
>>
>>
>

Attachment: 347.gif
Description: GIF image



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

(continued)

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

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

Werner Keil 10/17/2014

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

Martin Desruisseaux 10/18/2014

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

Leonardo Lima 10/17/2014

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

Martin Desruisseaux 10/18/2014

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

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

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

Werner Keil 10/18/2014
 
 
Close
loading
Please Confirm
Close