Skip to main content

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

  • From: Otávio Gonçalves de Santana < >
  • To:
  • Subject: Re: Remove "generic" multiply/divide operations from Quantity
  • Date: Wed, 1 Oct 2014 14:12:56 -0700

But returning to the thread,
Thank you, I did, I am waiting to question in Jira.

On Wed, Oct 1, 2014 at 1:51 PM, Otávio Gonçalves de Santana <
>
 wrote:

> Werner.
> I understood in some cases we need to do this cast, but it should be
> avoid, because it's not make sense with generics, generics was born to
> solve problems like this.
> We need to focus this will be a new API, so we should to use the new
> features present in ME 8+
>
>
> On Wed, Oct 1, 2014 at 12:06 PM, Werner Keil 
> < >
> wrote:
>
>> I just spoke to Paul Perrone after his Real Time Java Vehicle testing
>> talk.
>> He'd be interested to look at JSR 282 btw (happy to get him in touch with
>> Jean-Marie over that;-) but the important message from his slides is, that
>> almost every case where they derive something like:
>>
>> Sensor1 sensor1 = (Sensor1) sensorManager.getSensor(SENSOR1_ID); they use
>> cast and that is a realtime safety-critical system controlling cars or
>> drones[?]
>>
>> So casting can in some cases like mixed operations not be avoided
>> completely.
>> You're more than welcome to explore JSR 308 and its Unit Checkers for SE
>> 8+ and added safety at compile time. I spoke to Alex Buckley (a co Spec
>> Lead of 308) though he said, Oracle itself has practically no use for it.
>> And the feedback by Java EE Spec Leads at last night's BOF was equally
>> mixed to frosty.
>>
>> We discussed 308 here earlier, and e.g. Martin agreed it could help.
>> Would be only SE specific, so nothing for the API or Spec. Thus on the API
>> level we could have methods that allow cast and e.g. in ME 8 one will
>> probably have to without extra checking by JSR 308, etc. See Perrone the
>> industry uses that today and they control cars or patient monitors with
>> those embedded systems. In my previous project this was quite similar in
>> the train control business btw.
>>
>> HTH,
>> Werner
>>
>> On Wed, Oct 1, 2014 at 11:58 AM, Otávio Gonçalves de Santana <
>>
>>  wrote:
>>
>>> The problem is using cast with genetics almost always means problem with
>>> design API.
>>> On Oct 1, 2014 11:49 AM, "Werner Keil" 
>>> < >
>>>  wrote:
>>>
>>>> Sure, that is good. As we would at most consider the mentioned
>>>> alternate method (it looks a bit scary with so many generic arguments
>>>> though;-) I rejected the current one as it does not seem feasable. Please
>>>> let's see what comments come up in JIRA or here then we're happy to
>>>> consider another pull request for this topic.
>>>>
>>>> Thanks,
>>>> Werner
>>>>
>>>> On Wed, Oct 1, 2014 at 11:35 AM, Otávio Gonçalves de Santana <
>>>>  >
>>>>  wrote:
>>>>
>>>>> I am just created the pull request,  don't pull the code,  of course I
>>>>> will wait this discussion.
>>>>> On Oct 1, 2014 11:18 AM, "Werner Keil" 
>>>>> < >
>>>>>  wrote:
>>>>>
>>>>>> Yes I am. You may need to subscribe to the ticket.
>>>>>>
>>>>>> Please be patient with actual changes to the code. We heard by Bruno
>>>>>> at the JCP EC you are very eager to help and it was also a key factor 
>>>>>> that
>>>>>> earned you the JCP Award the other day, but the API and prior efforts 
>>>>>> (all
>>>>>> the way back to JSR 208) have a long history and lived as Open Source
>>>>>> projects (even in several "forks" see UCAR) for over a decade now. 
>>>>>> Some are
>>>>>> used by other standards, see GeoAPI, so a level of compatibility and
>>>>>> consistency with existing API is about as important as for a part of 
>>>>>> the
>>>>>> JDK itself. Hence, let's be careful and gentle with any structural 
>>>>>> change
>>>>>> and not rush things.
>>>>>>
>>>>>> Thanks,
>>>>>> Werner
>>>>>>
>>>>>> On Wed, Oct 1, 2014 at 7:19 AM, Otávio Gonçalves de Santana <
>>>>>>  >
>>>>>>  wrote:
>>>>>>
>>>>>>> Are you guys received some alerts when someone comments this issue?
>>>>>>> I am not :(
>>>>>>>
>>>>>>> BTW: I added a comment:
>>>>>>> https://java.net/jira/browse/UNITSOFMEASUREMENT-59
>>>>>>>
>>>>>>> On Tue, Sep 30, 2014 at 4:02 PM, Werner Keil 
>>>>>>> < >
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> However while specialized implementations are allowed, I don't
>>>>>>>>> think
>>>>>>>>> they are needed. A single implementation can handle every standard
>>>>>>>>> subtypes (Speed, Time, Length, etc.), provided that the
>>>>>>>>> QuantityFactory
>>>>>>>>> implementation is complete enough.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> No objections to that.
>>>>>>>>
>>>>>>>> In fact, using the additional domain "si.uom" I spawned a separate
>>>>>>>> library for those. While SI quantity types (being just interfaces) 
>>>>>>>> should
>>>>>>>> be in the API this is an extension to either RI or SE implementation 
>>>>>>>> (since
>>>>>>>> it extends AbstractQuantity or a similar base type) and can live 
>>>>>>>> quite well
>>>>>>>> in a separate module.
>>>>>>>>
>>>>>>>> Werner
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> > Martin, could you open a JIRA ticket for the suspect type issue
>>>>>>>>> on
>>>>>>>>> > inverse, please?
>>>>>>>>>
>>>>>>>>> As said in my previous email, I tried but JIRA seems partially down
>>>>>>>>> tonight. Will try again tomorrow.
>>>>>>>>>
>>>>>>>>>     Martin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Otávio Gonçalves de Santana
>>>>>>>
>>>>>>> blog:     http://otaviosantana.blogspot.com.br/
>>>>>>> twitter: http://twitter.com/otaviojava
>>>>>>> site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
>>>>>>> 55 (11) 98255-3513
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>
>
> --
> Otávio Gonçalves de Santana
>
> blog:     http://otaviosantana.blogspot.com.br/
> twitter: http://twitter.com/otaviojava
> site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
> 55 (11) 98255-3513
>
>


-- 
Otávio Gonçalves de Santana

blog:     http://otaviosantana.blogspot.com.br/
twitter: http://twitter.com/otaviojava
site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
55 (11) 98255-3513

GIF image



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

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

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

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
 
 
Close
loading
Please Confirm
Close