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 13:59:58 +0100

Jean-Marie/all,

Thanks for the input.
E.g. Fowler *martinfowler.com/apsupp/apchap3.pdf in a paper forestalling
the whole "Quantified Self" movement (he is often bevore his time[?]) not
only showed how to use Quantity in a Glucose Meter app, but there he has
Measurement with Quantity embedded. Subclassing (or -interfacing) in a
sense also fulfills a similar purpose in the API.*
<https://www.google.de/?gws_rd=ssl#>

With
 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)
}
What would then be left for Quantity?[?]

Especially all operations there depend on the Unit, thus doing the same on
Quantity would work, but without Unit one would likely be forced to cast if
the signature was
Quantity.multiply(Quantity)
rather than
Measurement.multiply(Measurement)

Fowler btw. drafted "his" Quantity not only with a getUnit() method but a
"number" value and all relevant operations. He saw Measurement more as the
process of measuring. A bit like OSGi Measurement where aside from
calculations, a numeric getter and a simple (but limited runtime safe) Unit
getter it has additional properties like "timestamp".

A Little while ago for an experimental "0.7" draft of the old Unit-API I
indeed had this discussion, mostly with Martin (in this EG, not Fowler[?])
the hierarchy drafted so far was a result. I hope, Martin agrees with your
proposal. If the location of arithmetic operations can be clarified, I
would consider it a somewhat cleaner solution, since the current
Measurement<Q estends Quantity<Q>> signature almost seemed a bit like a
circular Thing given Quantity then extends Measurement[?]

We had a discussion about "service" to be renamed to "spi" during recent
calls and F2F.
Not all but many JSRs have the concept of SPI, it is largely influenced by
Java Service Provider and Service Loader mechanism. A nice example given
here (even for weather and temperature[?])
http://www.developer.com/java/article.php/10922_3848881_2/Service-Provider-Interface-Creating-Extensible-Java-Applications.htm

About the ValueSupplier vs. Supplier argument, I hear that all the time
here, but fact is, you can neither use Java SE 8 Supplier in ME 8 (a key
target Environment for this JSR) nor do
Quantity extends Supplier<Number>, Supplier<Unit<Q>>

ValueSupplier is used in dozens of places at least in the RI. The main idea
is, to allow non-numeric values especially in ME (where you don't have the
SE 8 stuff) to be treated the same way. If we clarify what Quantity as
super-Interface of a "new" Measurement would actually be good for, other
than holder of the generic type-safe Interfaces, maybe that can be
answered, too.

The current Measurement Interface is intended for e.g. the typical T-Shirt
size ("Small", "Medium", "Large",...) which are non-numeric, but one would
want a getValue() for that which is normally a String, comparison in that
case is custom-specific, but "S<M<L" works and should return the matching
result for Comparable<TShirtSize>[?]

Wikipedia acutally backs your proposal:
http://en.wikipedia.org/wiki/Quantity
"A quantum is a plurality if it is numerable, a magnitude if it is
measurable." (here comes Measurable again, but let's stick to Measurement
if we can[?])

So Quantity could be used for "a few" or "a couple", T-shirt sizes or Agile
Story Points (unless they are actual numbers) while Measurement would be
what Quantity is at the Moment.

WDYT?

Then ValueSupplier offers a standardized way of providing non-numeric
values just as numeric values both on ME and SE (where Supplier is never a
true alternative, what would get() return if used, the value, the unit or
something else[?])

Based on JSR 354 moving some enums like DisplayStyle to the Moneta RI, that
makes sense here, too.
JSR 310 which also added a few of these to Java SE 8 (java.time.format) is
a fairly bad example since the only part that could somewhat be considered
"API" is just the "temporal" package, everything else is just the RI[?]

Removing DimensionService seems fine, as Dimension is so far not
instanciated by itself.

About "spi" vs. "service" I am not religiously bound to either, as long as
we refrain from horribly things like reversing the whole thing like in
"javax.batch.api".
Agorava uses the "api" package, but its package space is shared by
potentially many other connectors like "org.agorava.facebook",  so "api"
and "spi" (with things like UserProfileService or mainly OAuth
infrastructure to extend in your own Services) stick out, but it is
practically unused by any JSR under Java SE or EE.

Cheers,
Werner

On Fri, Oct 31, 2014 at 12:30 PM, Jean-Marie Dautelle 
< >
wrote:

> Another comments. Since most the user would want Measurement and not (too
> abstract) quantities. It would make sence to provide MeasurementService
> (and Measurements class) instead of QuantityService (and Quantities
> classes). You might also want to shorten the name "Measurement" to
> "Measure".
> Cheers,
> JM
>
> On Fri, Oct 31, 2014 at 12:26 PM, Jean-Marie Dautelle 
> < >
> wrote:
>
>> Dear All,
>>
>> In order to be able to answer the question, I took this opportunity to
>> check the overall consistency of the unit-api.
>>
>> Overall I am happy with it  :) providing we correct a few important
>> things.
>>
>> Package spi:
>>    - I would recommand to rename this package "service" (or "factory" if
>> we replace "Service" with "Factory" in all the classes' names).
>>    - DimensionService is unnecessary/confusing. The dimensions instances
>> should be created through the Unit.getDimension method.
>>    - QuantityService (or QuantityFactory) should be here  (and not in the
>> package function)
>>
>> Package quantity:
>>    - Perfect :)
>>
>> 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).
>>
>> Package format:
>>  - Classes UnitStyle and FormatBehavior are not used in the API and
>> should be removed or moved to the RI (if being used by the RI).
>>
>> 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)
>>
>>  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)
>> }
>>
>> 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 !
>>
>> Cheers,
>> Jean-Marie.
>>
>>
>>
>> On Thu, Oct 30, 2014 at 3:25 PM, Werner Keil 
>> < >
>> wrote:
>>
>>> Hi,
>>>
>>> As Antoine just did some of those for CDI 2 on the Mailing list, let me
>>> also try the same here. The last doodle triggered so much discussion on 
>>> the
>>> Mailing list, that the question probably could have been asked here in the
>>> first place, too[?]
>>>
>>> Should *Quantities *(
>>> https://github.com/unitsofmeasurement/unit-ri/blob/master/src/main/java/tec/units/ri/quantity/Quantities.java)
>>> return
>>> 1) a *Quantity *instance like it does now in both RI and SE port
>>>     or
>>> 2) a *QuantityFactory*?
>>>     similar to what JSR 354 does with MonetaryAmounts:
>>>
>>> https://github.com/JavaMoney/jsr354-api/blob/master/src/main/java/javax/money/MonetaryAmounts.java
>>> )
>>>
>>> See https://java.net/jira/browse/UNITSOFMEASUREMENT-65
>>> The outcome decides, whether we treat QuantityFactory as a
>>> core/mandatory part of the API (keeping it under "function" I think it's
>>> better than a slightly cluttered impression javax.money makes with 30 top
>>> level elements[?]) or should move it to the optional SPI (which is
>>> optional especially because the entire service part is optional in MEEP,
>>> too, hence providing services on a device that has no use for it would be 
>>> a
>>> waste)
>>>
>>> Iit is not directly related to
>>> https://java.net/jira/browse/UNITSOFMEASUREMENT-67 but both aim at
>>> static "convenience factory" methods.
>>>
>>> Making this simple, please try to reply like
>>> +1 for 1)
>>> or
>>> +1 for 2)
>>>
>>> not with a too lengthy discussion around it yet. It worked well for JSR
>>> 365, hope we can also get similar results here[?]
>>>
>>> Thanks,
>>>
>>>  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)
>>
>
>
>
> --
> 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: 338.gif
Description: GIF image

Attachment: 35F.gif
Description: GIF image

Attachment: 329.gif
Description: GIF image

Attachment: 347.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

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

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

Otávio Gonçalves de Santana 10/30/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

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