Use Advanced Search to search the entire archive.
Re: Remove "generic" multiply/divide operations from Quantity
- From: Werner Keil <
>
- To:
- Subject: Re: Remove "generic" multiply/divide operations from Quantity
- Date: Fri, 17 Oct 2014 02:09:09 +0200
Jean-Marie,
Thanks for the update. Happy to wait, till you're able to cast your opinion.
Aside from all EG members who have an opinion, just like others e.g. 354
the last word is with Spec Leads.
Please for this question, look at JavaDoc of current Quantity:
http://www.unitsofmeasurement.org/jsr-363/apidocs/javax/measure/Quantity.html
The signature of
multiply(Quantity)
Is based on Otavio's suggestion to replace the wildcard <?> with a choice
of typing like <T>. Note, developers may also use Quantity <?> in their
code, otherwise a return type they feel is appropriate like
Quantity<Area> area = Quantity<Length>.multiply(length)
Where no cast to (Quantity<Area>) is required.
divide(Quantity)
shows the old form. One may return Quantity<?> without cast, everything
else, especially say Quantity<Area> requires a cast.
Otavio argues the wildcard version in need of a cast was "old style" and
frankly some new JEPs like JEP101 go in a similar direction.
(hence asking OpenJDK guys for their opinion would not be entirely bad, but
being a non-platform JSR I'm not sure, if they feel responsible?;-)
Martin feels, semantically <?> or an otherwise enforced cast was more
correct, hence he prefers to keep the signature like in
Quantity.divide(Quantity<?>).
The question is simply about these two signatures.
Anything else, e.g. additional asType() methods, etc. shall be answered
separately.
JScience 5 or 6 will likely implement the new JSR, so you should have an
idea on methods that would be implemented by classes like the current
Amount (v 4.3)
Thanks and Regards,
Werner
Hi Guys,
I tred to read through the emails but I failed to understand the question !!
Werner or Martin could you pose the question in simple terms that we can
all answer by yes or no.
I am in training all week but I will try to give you my opinion / response.
Cheers,
JM
Hi Guys,
I tred to read through the emails but I failed to understand the question !!
Werner or Martin could you pose the question in simple terms that we can
all answer by yes or no.
I am in training all week but I will try to give you my opinion / response.
Cheers,
JM
On Thu, Oct 16, 2014 at 10:11 PM, Werner Keil
<
>
wrote:
>
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
>
>>
>
>>
>
>
>
--
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)
Attachment:
347.gif
Description: GIF image