Skip to main content

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

  • From: Jean-Marie Dautelle < >
  • To:
  • Subject: Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory
  • Date: Fri, 31 Oct 2014 16:58:09 +0100

>It is meant to standardize usage of the value part. If we left ME users to
die without it and SE users to something weird like
>getUnit() and
>get()

Actually it would be
getUnit()
getValue()
(implementing a functional interface is not necessary nor required).



On Fri, Oct 31, 2014 at 2:32 PM, Werner Keil 
< >
 wrote:

> Hi, more inline
>
>
>
>
> On Fri, Oct 31, 2014 at 12:50 PM, Martin Desruisseaux <
>  >
>  wrote:
>
>> Thanks Jean-Marie for looking on the API.
>>
>> Le 31/10/14 20:26, Jean-Marie Dautelle a écrit :
>> > Package spi:
>> >    - I would recommand to rename this package "service" (or "factory"
>> > if we replace "Service" with "Factory" in all the classes' names).
>> I'm somewhat neutral on this one. However JavaSE consistently use "spi"
>> everywhere (java.util.spi, java.text.spi, etc.). How would we justify a
>> departure?
>>
>
> As mentioned, it is common practice by most JSRs or parts of the platform,
> so it seems natural to call it "spi".
>
>
>
>>
>> >    - QuantityService (or QuantityFactory) should be here  (and not in
>> > the package function)
>> I agree.
>>
>> > Package function:
>> >   - I understand that we want to put here functional methods, but
>> > there are actually only two functional interfaces closely related to
>> > the unit-api : Unit and Measurement conversion methods
>> >     Therefore, I would keep MeasurementConverter and UnitConverter but
>> > all the others classes should be removed  (ValueSupplier is another
>> > name for Java 8 Supplier).
>> Ton of +1 !! Me too I think that ValueSupplier should be considered out
>> of JSR-363 scope.
>>
>>
> It is meant to standardize usage of the value part. If we left ME users to
> die without it and SE users to something weird like
> getUnit() and
> get()
> (wtf does it get?;-)
> then we could remove it
>
>
>>
>> > Package measure:
>> >  - There is a hierarchical inversion! Measurement should extends
>> >  extends Quantity and not the inverse (a measurement is a quantity
>> > "measured"; hence with a value stated in a unit)
>> Or alternatively, we may try to rename Measurement in something else.
>> Indeed it may be preferable to avoid any type named "Measurement" in
>> JSR-363, because many groups have a much more complex idea of what a
>> measurement is (e.g. must have an estimation about accuracy or quality,
>> etc.). In our case, the "Measurement" idea was "something (not
>> necessarily a scalar) with a unit of measure". For example a vector is
>> not a scalar quantity, but still have a unit of measurement. So as I see
>> it, the open question is: how to rename "Measurement" for catching the
>> idea of "something with a unit of measure"?
>>
>>
>> >  interface Measurement<Q> extends Quantity<Q> {
>> >      Number getValue()
>> >      Unit<Q> getUnit()
>> >      toUnit(Unit<Q>) // toUnit should be here and not in the Quantity
>> > interface (a quantity intrinsically has no unit)
>> > }
>> Actually the above hierarchy may fit the vocabulary, but is different
>> than the current Quantity intend. It may be a vocabulary problem: what
>> we call "Quantity" in JSR-363 is actually a "Scalar" for physicists.
>> Renaming "Quantity" as "Scalar" would have be more accurate for those
>> familiar with physics science and would make sense with the current
>> hierarchy (we could even keep the current Measurement interface). But
>> "Scalar" has been discarded because too many peoples are not familiar
>> with this term.
>>
>> Do we start a separated thread named "Agree on quantity, measurement and
>> scalar definitions" and see if we revisit some interface name accordingly?
>>
>>
>>
> Scalar sounds a bit too mathematical or scientific. While I understnd it
> and so would the likes of Mark Reinhold or others in the OpenJDK Team, most
> normal users wouldn't.
> Alone the increasingly popular "Quantified Self" movement which has
> Quantity already in its name, too[?]
>
> Wikipedia backs the idea of Quantity as a root object:
> http://en.wikipedia.org/wiki/Quantity
>
> It refers to a PhysicalQuantity:
> http://en.wikipedia.org/wiki/Physical_quantity somewhere along the lines
> of JScience 5, but when I spoke to some other EC members last year before
> we actually proposed the new JSR they said, the "physics" module of
> JScience or words like "PhysicalQuantity" would sound a bit restrictive.
> Given a "NumericQuantity" can of course be used by economics for
> (non-financial) Benchmarks, or Project Management, Agile or not.
>
> I'd create a JIRA task for that. While a discussion thread is also valid
> to make up our minds,
>
>
>> > Now for the vote, to be consistent with the comments above.
>> > In the RI we should have: class Quantities implements QuantityService;
>> >  hence the Quantities methods should return Quantity instances !
>> But an implementation does not need to expose publicly its
>> QuantityService implementation. If Quantities does nothing else than
>> implementing QuantityService, then it does not need to be public. I
>> though that the only point to make Quantities a public class would be
>> convenience, in the form of static methods. This also match the usual
>> JavaSE practice, where classes in plural form are usually a set of
>> static methods (e.g. java.util.Collections).
>>
>
> I guess also inspired by JSR 354 which is full of those "s" convenience
> factories Otavio wanted to provide such a convenience facade.
> We seriously have to also look at
> https://java.net/jira/browse/UNITSOFMEASUREMENT-67, since those
> convenience factories, whether it's on the abstract base class, concrete
> class or (not yet possible till ME gets Lambdas or default methods)
> Interface directly compete with such convenience method in a class like
> Quantities.
> I see a main reason for JSR 354 exposing the factory, not the Money type
> from MonetaryAmounts, because RI types like Money themselves provide an
> of(() method.
>
>
>>     Martin
>>
>>
>>
> Werner
>
>


-- 
It is not the strongest of the species that survives, nor the most
intelligent. It is the one that is most adaptable to change. - Darwin's
Origin of Species (digest)

Attachment: 329.gif
Description: GIF image



Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

(continued)

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Werner Keil 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Martin Desruisseaux 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Otávio Gonçalves de Santana 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Martin Desruisseaux 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Werner Keil 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Jean-Marie Dautelle 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Jean-Marie Dautelle 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Werner Keil 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Martin Desruisseaux 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Werner Keil 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Jean-Marie Dautelle 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Martin Desruisseaux 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Werner Keil 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Martin Desruisseaux 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Werner Keil 10/31/2014
 
 
Close
loading
Please Confirm
Close