Skip to main content

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

  • From: Werner Keil < >
  • To: " " < >
  • Subject: Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory
  • Date: Fri, 31 Oct 2014 14:32:48 +0100

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

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

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

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