Skip to main content

Re: Proposal

  • From: Werner Keil < >
  • To:
  • Subject: Re: Proposal
  • Date: Mon, 17 Nov 2014 13:45:47 +0100

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
>
>


Re: Proposal

(continued)

Re: Proposal

Martin Desruisseaux 11/03/2014

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