Skip to main content

Re: Proposal

  • From: Jean-Marie Dautelle < >
  • To:
  • Subject: Re: Proposal
  • Date: Sun, 2 Nov 2014 12:22:19 +0100

Hi,

I will try to be as succinct as possible.

> While the current layout declares a "quantity" package optional, we would
end up with a much bigger JAR (hence split from "core"/"base" quite
inevitable;-) and in any case a giant wormhole TCK;-O

No, for the API only a few methods (may be a dozen) will be added (the
methods for which multiply/divide returns an existing predefined quantity).
For the implementation, I would estimate this change to an extra 40 KBytes
maximum, peanuts in term of JAR size, of course I would assume that the
implementation uses a quantity base class with most operations implemented.

>Why massOf(Lenght)?;-)
>Again, if we agreed on keeping it optional in a bundle like SPI that could
work but it feels horribly bloated, worse than 310 which only got
>ofNanos(), ofMillis() or of years().

This could be simplify to
 interface QuantityFactory<N extends Number> {
    Q extends Quantity<Q> Q valueOf(N, Unit<Q>);
}

But will it compile?

I don't think the would bloat the API. We have only *one* interface with
about 40 convenient methods all using similar naming convention (not the
same as dozens of extra classes)

> That implies only reducing it to "magnitude" (see
http://en.wikipedia.org/wiki/Quantity) ?

Yes indeed, we don't need the Measurement/MeasurementConverter interface
(unbloating).

> I assume that's the old nomenclatura from 0,6, or do you propose to keep
that rather than getUnit() or getValue()?

I have no strong feeling about that (what the majority think is best).

I am sure we can converge on something simple, practical, extendable and
user friendly [?]

Cheers,
JM


On Sun, Nov 2, 2014 at 11:40 AM, Werner Keil 
< >
 wrote:

> Hi,
> Answers inline
> Am 02.11.2014 10:51 schrieb "Jean-Marie Dautelle" 
> < >:
> >
> > Hello all,
> >
> > I understand your points, but I have the feeling that we are making
> things more difficult than they need to be.
> >
> > We should not forget that the main subject is the unit-api not the
> "quantity-api".
> >
> > Let's put ourselves in the shoes of the user and see what he might want
> to do:
> >
> > public void wait(Time delay) { ... }
> > Mass m = parcel.getWeight();
> >
> > I would assume that until that point everyone agree...
> >
> > Let's go deeper, we might want to do also:
> >
> > Length x = ...
> > Time t = ...
> > Velocity v = x.divide(t);
> >
> > If we can do that then I believe that even more people will be happy
> (especially if it does not involve reflection)
> >
> > ... And YES, it is possible!
> >
> > The first thing we see is that some of the quantities interfaces will
> have extra methods.
> >
> > interface Length extends Quantity<Length> {
> >      Area multiply(Quantity<Length>); // Overloading.
> > }
> > interface Area extends Quantity<Area> {
> >      Volume multiply(Quantity<Length>); // Overloading.
> > }
> > Length x = ...
> > Volume v = x.multiply(x).multiply(x);
> >
> > There is no combination explosion since the number of predefined
> quantities is bounded. Furthermore, all these are convenient (optional)
> methods, the asType(Class<Q>) method can be used for complex cases.
> >
>
> While the current layout declares a "quantity" package optional, we would
> end up with a much bigger JAR (hence split from "core"/"base" quite
> inevitable;-) and in any case a giant wormhole TCK;-O
>
> Currently this is subject to implementations. Unit tests in the API
> created with Paul's help in the 0.6 stage demonstrate it.
>
> > The question now is how do we create these Quantity instances?
> >
> > For this problem, the abstract factory pattern (GoF) is a perfect fit.
> All quantities coming from the same factory will work well together and
> this approach allows for many many optimizations under the hood !
> >
> > // Unit-API
> > interface QuantityFactory {
> >      Length lengthOf(double, Unit<Length>);
> >      Mass massOf(double, Unit<Length>);
> >      ...
> > }
>
> Why massOf(Lenght)?;-)
> Again, if we agreed on keeping it optional in a bundle like SPI that could
> work but it feels horribly bloated, worse than 310 which only got
> ofNanos(), ofMillis() or of years().
>
> >
> > // Unit RI
> > abstract class Quantities {
> >      public static QuantityFactory DOUBLE = ...;
> >      public static QuantityFactory BIG_DECIMAL = ...;
> > }
>
> Hiding these behind a service could be cleaner, but it is up to
> implementations.
>
> >
> > Length x = DOUBLE.lengthOf(2.4, METER);
> > Length two_x = x.add(x);
> > Area x_square = x.multiply(x);
> >
> > (Note: I would have preferred plus, minus, time, divide but I can live
> with that )
> >
>
> The likes of Groovy or Scala partly used that naming. In Java only JSR 310
> did some weird and totally uncommon mix of addTo(), plus(), dividedBy() or
> times(), from different interfaces / concrete classes. Neither naming nor
> overloading was done well in 310 and you see the horrible method bloating
> by minusDays(),...
>
> I have the feeling we could end up with something like
>
> Area = timesLength(Length) or
>
> Volume = timesArea(Area), too, [?]
>
> > There is no need for a Measurement class (and MeasurementConverter).
>
> That implies only reducing it to "magnitude" (see
> http://en.wikipedia.org/wiki/Quantity) ?
>
> As Martin asked earlier, what an enum would do when implementing Quantity,
> well in the current design it implements Measurement, the "abstract
> quantity", not Quantity which reflects "magnitude" or "numeric quantity".
>
> While it uses a fairly strange relationship between Unit and Quantity,
> leaving that aside, I must say, OpenXC solved that pretty well:
>
> http://android.openxcplatform.com/reference/com/openxc/units/Unit.html
>
> - Quantity is a Numeric quantity, hence it even allows only numbers to
> instanciate (could chose between e.g. Double and BigDecimal if you want)
>
> - State is the "multitude" based on an Enum but also inheriting from what
> OpenXC calls Unit.
>
> - Boolean for simple On/Off cases, meaning even they are typed by OpenXC,
> so you know the unit for "ignition" opposed to  "lights" or similar.
>
> While I am not sure, if we should offer 3 similar detail types (OpenXC
> uses concrete classes for almost everything) it would be good to at least
> offer the choice. Otherwise many use cases in Embedded, not just Automotive
> could be locked out and left to create yet their own API.
>
> >
> > The quantity base class will be very close to what we have now except it
> does not implement any interface.
> >
> > public interface Quantity<Q extends Quantity> {
> >       Unit<Q> unit();
> >       Number value();
> >       double doubleValue(Unit<Q>); // To avoid boxing/deboxing.
> >       Quantity<Q> add(Quantity<Q>);
> >      ...
> > }
>
> I assume that's the old nomenclatura from 0,6, or do you propose to keep
> that rather than getUnit() or getValue()?
>
>
> >
> > Of course if we can converge on this solution I would be really really
> happy (JScience has many types of numbers such as Rational, Complex for
> which this approach is a perfect fit) !!!
> >
> > Best regards,
> > Jean-Marie.
>
>
> Regards,
>
> 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: 341.gif
Description: GIF image

Attachment: B68.gif
Description: GIF image



Re: Proposal

(continued)

Re: Proposal

Werner Keil 11/02/2014

Re: Proposal

Jean-Marie Dautelle 11/02/2014

Re: Proposal

Jean-Marie Dautelle 11/02/2014

Re: Proposal

Werner Keil 11/02/2014

Re: Proposal

Jean-Marie Dautelle 11/02/2014

Re: Proposal

Martin Desruisseaux 11/02/2014

Re: Proposal

Werner Keil 11/02/2014

Re: Proposal

Jean-Marie Dautelle 11/02/2014

Re: Proposal

Jean-Marie Dautelle 11/02/2014

Re: Proposal

Werner Keil 11/02/2014

Re: Proposal

Jean-Marie Dautelle 11/02/2014

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
 
 
Close
loading
Please Confirm
Close