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