Skip to main content

Re: Proposal

  • From: Werner Keil < >
  • To: " " < >
  • Subject: Re: Proposal
  • Date: Mon, 17 Nov 2014 22:56:41 +0100

Sorry but please look at MEEP 8 on how they did that. The concept of
optional packages may be new, not so easy to understand for those with
strong SE/EE mindet, but it worked well for MEEP and as you mentioned, we
"also" target ME so we need to cater to its needs by applying what MEEP did
already[?]

"Lib" is not part of the spec we define here, so especially for vital
things like SI units these should be in the spec not some extra that
everyone has to redefine.
They can use either all of the optional quantity bundle or none if it's an
extremely small device.

HTH,
Werner

On Mon, Nov 17, 2014 at 7:20 PM, Otávio Gonçalves de Santana <
>
 wrote:

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

Attachment: 329.gif
Description: GIF image



Re: Proposal

(continued)

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