Skip to main content

Re: Proposal

  • From: Werner Keil < >
  • To:
  • Subject: Re: Proposal
  • Date: Mon, 17 Nov 2014 05:14:15 +0100

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


Re: Proposal

(continued)

Re: Proposal

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

Re: Proposal

Werner Keil 11/02/2014

Re: Proposal

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

Re: Proposal

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

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