Use Advanced Search to search the entire archive.
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