Skip to main content

Re: Proposal

  • From: Otávio Gonçalves de Santana < >
  • To:
  • Subject: Re: Proposal
  • Date: Mon, 17 Nov 2014 16:20:05 -0200

If it is optional, so why stay in JSR-API?

Maybe create a quantity-lib to keep this interfaces.



On Mon, Nov 17, 2014 at 10:45 AM, Werner Keil 
< >
 wrote:

> That's already done, but at least SI scope base quantities are essential
> to type-safety and they while extending Quantity are API, they are not
> meant to be implemented in most cases but serve Generics. Those are
> optional, so people can either use them or define their own.
> It makes little sense to redefine SI which is standardized as such, hence
> this standard offers the standard types;-)
> Am 17.11.2014 13:38 schrieb "Otávio Gonçalves de Santana" <
>  >:
>
> I think is more interesting just standardize the measurement.
>> Keep in the API the Quantity and Unit and move to RI the Quantity
>> specializes such Speed, Length, etc., for example, not make sense a make an
>> API to ME measuring weight, an API for balance, that should implement
>> Speed, the creator will not implement the JSR 363.
>> If our API is simple to use and create, the same people, who will create
>> the API for balance, could easily use the the JSR 363 to represents the
>> width model. The sample follows to gas machine, to measure the fuel, it
>> will use just litre.
>> In other words, how it is a JSR is important to think the another peoples
>> who want implement it. So we should to try standardize the measure model.
>>
>> Another stuff to API, library, frameworks, etc.
>>
>> On Mon, Nov 17, 2014 at 9:02 AM, Werner Keil 
>> < >
>> wrote:
>>
>>> We are no longer separating ME vs. SE/EE and this JSR is the first of
>>> its kind beside Oracle's own platform JSRs like 361.
>>> So we must not repeat the mistake of JSR 256 which was a total failure
>>> and used by nobody.
>>>
>>> You're concerned with casts, well, crippling the API would make explicit
>>> casts inevitable and force developers to cast to the RI or "library" class
>>> every time they needed to do a trivial thing like multiply or divide. That
>>> is unacceptable to most users. Worse, a concrete type implementing say
>>> JScienceQuantity will be incompatible with other implementations like
>>> MySEQuantity in other implementations.
>>>
>>> We don't need ultra precision like 354, but basic needs like add,
>>> subtract, divide or multiply are the same and this JSR blends in with 354
>>> into a new generation of "Value JSRs" eventually catering to real value
>>> types if Java gets there.
>>> All we know, is Value objects can and must be able to implement
>>> interfaces, thus what we define in the API becomes available to a true
>>> value object, what's in some obscure library or an implementation won't;-)
>>>
>>> What we likely will refrain is adding all these custom methods like
>>> Length.divide(Time) to types in the "quantity" package, but we must
>>> provide the simple generic ones for usefulness of the API.
>>>
>>> Note "quantity" is optional, but it may make more sense to move a
>>> Length.divide(Time) method to a class like LengthAmount in the SI module.
>>>
>>> Werner
>>> Am 17.11.2014 11:02 schrieb "Otávio Gonçalves de Santana" <
>>>  >:
>>>
>>> Werner, it is the problem, no make sense do the same stuff to different
>>>> JSR, because the goal is different, now we are looking for ME platform.
>>>>
>>>> And Yes, it impact in the size, we have, for example, 4 implementations
>>>> for Unit, 5 classes in internal and classes that do the validation and 
>>>> make
>>>> another unit, for example, Length divided for Time results in Speed.
>>>> Another problem is power processor to validate this think.
>>>>
>>>> I not saying to remove directly, just use as lib and/or as framework to
>>>> get more modularity.
>>>>
>>>> On Mon, Nov 17, 2014 at 2:14 AM, Werner Keil 
>>>> < >
>>>> wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> IMHO it'll considerably remove usefulness from both. There's
>>>>> practically no difference in size added by 2 methods in Quantity nor in
>>>>> Unit.
>>>>>
>>>>> I was on the MEEP EG and the only real way we could further improve
>>>>> minimal size for tiniest ME devices is to break the API into one JAR per
>>>>> package. The new structure with 3 of those at the moment would make that
>>>>> rather simple compared to MEEP. And for SE/EE we can offer a 
>>>>> "convenience"
>>>>> all in one JAR.
>>>>>
>>>>> JSRs like especially 354 offer similar methods on an API level to
>>>>> users. They are bound to SE only by Lamdas, but unlike Jigsaw/Module JSR
>>>>> (Yes, there should be one, but likely never for ME;-) it might come to 
>>>>> ME
>>>>> with V9 or so, then a JavaMoney implementation is possible on at least a
>>>>> bit larger devices, too.
>>>>>
>>>>> Furthermore especially on Quantity (which they called Measurement, we
>>>>> moved the "measuring" part to implementations because that allows adding
>>>>> say JSR 310, etc. but in theory the slim Measurement interface with 2
>>>>> getters could also be added to the API in future;-) existing Measurement
>>>>> APIs like OSGi Measurement offer divide/multiply operations. If we 
>>>>> crippled
>>>>> the API, a vast majority of projects interested in adopting JSR 363 
>>>>> would
>>>>> either stick with the defunct 275 (e.g. if we provided no real 
>>>>> improvement
>>>>> over it, which alone a clear API/RI separation already does;-) or those
>>>>> OSGi "enhancements" especially in the Eclipse or Embedded world.
>>>>>
>>>>> It wouldn't be enough to cripple the API and leave just 2 operations
>>>>> away to say offer Jean-Marie and JScience a freedom to call it 
>>>>> times/divide
>>>>> instead of multiply/divide. He also suggested plus/minus instead of
>>>>> add/subtract;-)
>>>>>
>>>>> I would however rather rename those on an API level creating a slight
>>>>> inconsistency with everything in the Java world that does this except 
>>>>> the
>>>>> "Alien" JSR 310 where operations have a weird, inconsistent mix of 
>>>>> Scala,
>>>>> Ruby or Groovy naming for these basic arithmetic operations.
>>>>>
>>>>> Everything else from BigDecimal to OSGi (slightly abbreviated as
>>>>> div/mul, but nowadays descriptive method names are often better than 
>>>>> ultra
>>>>> short ones thanks to auto-completion and new compilers:-) JavaMoney or
>>>>> JavaFX calls them the same consistent way.
>>>>>
>>>>> Werner
>>>>> Am 17.11.2014 03:49 schrieb "Martin Desruisseaux" <
>>>>>  >:
>>>>>
>>>>>  Hello Otavio
>>>>>> Le 17/11/14 11:05, Otávio Gonçalves de Santana a écrit :
>>>>>>
>>>>>> (...snip...) I believe would be better remove this operations
>>>>>> (multiply, divide, invert) both Unit and Quantity.
>>>>>>
>>>>>> I'm neutral about removing them from Quantity - I understand that
>>>>>> some peoples may be uncomfortable with the lack of type safety, and I 
>>>>>> think
>>>>>> that providing any operation in Quantity (including add and
>>>>>> subtract) is of limited use because of the performance impact compared 
>>>>>> to
>>>>>> working on the double type directly. However removing those
>>>>>> operations from Unit is a different story, as it would considerably
>>>>>> reduce the usefulness of this library.
>>>>>>
>>>>>>
>>>>>>    - *The main platform to JSR 363 is ME:* Beside we have plans to
>>>>>>    OpenJDK and Java SE platform, the main goal should be the ME, this 
>>>>>> way, we
>>>>>>    haven't features that help us such reflexion/proxy API.
>>>>>>
>>>>>>  Note that the need for reflexion/proxy API should be only for
>>>>>> Quantity, not for Unit.
>>>>>>
>>>>>>     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


Re: Proposal

(continued)

Re: Proposal

Martin Desruisseaux 11/03/2014

Re: Proposal

Martin Desruisseaux 11/03/2014

Re: Proposal

Werner Keil 11/03/2014

Re: Proposal

Otávio Gonçalves de Santana 11/17/2014

Re: Proposal

Martin Desruisseaux 11/17/2014

Re: Proposal

Werner Keil 11/17/2014

Re: Proposal

Otávio Gonçalves de Santana 11/17/2014

Re: Proposal

Werner Keil 11/17/2014

Re: Proposal

Otávio Gonçalves de Santana 11/17/2014

Re: Proposal

Werner Keil 11/17/2014

Re: Proposal

Otávio Gonçalves de Santana 11/17/2014

Re: Proposal

Werner Keil 11/17/2014
 
 
Close
loading
Please Confirm
Close