Skip to main content

Re: AbstractQuantity's class

  • From: Werner Keil < >
  • To: " " < >
  • Subject: Re: AbstractQuantity's class
  • Date: Mon, 15 Sep 2014 21:51:31 +0200

Dear Experts,

If you don't see a conflict between a more general "Amount" class here and
other types in different value-oriented APIs like JSR 354, we may take the
inspiration by the likes of JScience or ICU4J, both using *Amount for such
types.

ICU4J combines it with things like "Currency" in
http://icu-project.org/apiref/icu4j/com/ibm/icu/util/CurrencyAmount.html
the other concrete class is even called "TimeUnitAmount", but I would not
really see any of those as proper additions either.

How do you intend to use the "faster" quantity sub-types, currently all
returned by factory methods in AbstractQuantity?
The "Amount" type like e.g. that in ICU4J (there it is named Measure, but
unlike JSR 363 it does not separate between API and implementation, so
everything are classes) holds a Number, so in theory using different
concrete number sub-classes would work for
Amount.of(100d, SI.METRE) as opposed to
Amount.of(BigDecimal.TEN, SI.METRE) could handle that all.

What about alternate classes with a lower footprint, especially in SE?
Actually they might matter more, but if using objects like Double, Integer
or Long worked equally well under ME, we could and should keep that in
sync, with the exception of BigDecimal/BigInteger[?]

Martin, others WDYT?

Regards,
Werner

On Mon, Sep 15, 2014 at 9:07 PM, Otávio Gonçalves de Santana <
>
 wrote:

> Amount.of() sounds good.
> On Sep 15, 2014 4:04 PM, "Legrand, Karen" 
> < >
>  wrote:
>
>>  -1 for QuantityAmount.  It looks very odd to have two nouns that are
>> essentially synonyms together like that. I think it would be much better to
>> use either ‘Quantity’ or ‘Amount’ by itself.
>>
>>
>>
>>
>>
>>
>>
>> *From:* Leonardo Lima 
>> [mailto: ]
>> *Sent:* Monday, September 15, 2014 10:44 AM
>> *To:* 
>
>> *Subject:* Re: AbstractQuantity's class
>>
>>
>>
>> QuantityAmount sounds redundant, doesn't it?
>>
>>
>>
>> On Sun, Sep 14, 2014 at 9:03 PM, Otávio Gonçalves de Santana <
>>
>>  wrote:
>>
>> Actually I would like to work this and in Lambda expressions.
>>
>>
>>
>> Could be QuantityAmount then?
>>
>> anyone?
>>
>>
>>
>> On Sun, Sep 14, 2014 at 6:06 PM, Werner Keil 
>> < >
>> wrote:
>>
>> Since we drop the .org domain soon, I would not call that UOMo (the
>> Eclipse project certainly will keep the name, after all it also support
>> UCUM which has another .org domain, too)
>>
>> Why would Quantities get an of() method? What would be imaginable is some
>> sort of factory/facade in RI or SE, but except a getInstance(Length.class)
>> similar to the current QuantityFactory class (it's a singleton returning
>> exactly one instance here, see MEEP or CLDC8, they also use both of() and
>> getInstance() for each purpose, just like Josh Bloch explained) there is
>> nothing to be of() in this case.
>>
>>
>>
>> QuantityAmount sounds like a good alternative of these, let's see at
>> JavaOne, probably in Hackergarten what's best.
>>
>>
>>
>>
>>
>> On Sun, Sep 14, 2014 at 9:01 PM, Otávio Gonçalves de Santana <
>>
>>  wrote:
>>
>> I am not referring if the classe be or not be abstract or design, but
>> just the name, I am talking about the nomenclature.
>>
>>
>>
>> Could be a good name:
>>
>>    - UOMO.of(...)
>>
>>  another one is:
>>
>>    - Quantities.of(...)
>>
>>  or the classic:
>>
>>    - QuantityAmount.of(...)
>>
>>
>>
>> On Sun, Sep 14, 2014 at 2:51 PM, Werner Keil 
>> < >
>> wrote:
>>
>> Sorry, no more Measurable, please
>>
>> We've been there once.
>>
>>
>>
>> You bet Spring was probably created a while ago and may not follow all
>> patterns we may see now
>>
>>
>>
>> Something else e.g. QuantityAmount<Q extends Quantity> extends
>> AbstractQuantity<Q> is worth considering, like in UOMo.
>>
>>
>>
>> And the subsequent of() methods may be on such a concrete class.
>>
>> If you look at let's say the Collections API, it shows a similar pattern
>> of
>>
>> Interface > AbstractBaseClass > ConcreteClass.
>>
>>
>>
>> This "author" may not have done everything consistently there, see
>> EnumSet, but other than that it is still a better piece of API than let's
>> say 310 with hundreds of methods on final classes that are largely
>> incompatible and a TemporalAmount which actually should be called
>> TemporalAmounts, TemporalAmountCollection or whatever
>>
>>
>>
>>
>>
>> On Sun, Sep 14, 2014 at 8:32 AM, Werner Keil 
>> < >
>> wrote:
>>
>> Sorry but we had that confusion with JSR 275, so ONE Measurement is
>> enough, we must not have Measure implements Measurement, that would just be
>> a mess.
>>
>>
>>
>> JScience called that "Amount", but you see a lot of very popular projects
>> (SpringFramework) doing exactly the same. There are Abstract*.valueOf() or
>> similar constructions.
>>
>>
>>
>> Regards,
>>
>> Werner
>>
>>
>>   Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
>> Eclipse UOMo Lead, Babel Language Champion | Apache Committer | Java
>> Godfather
>>
>> Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social |
>> #DevOps
>>
>> Skype werner.keil | Google+ gplus.to/wernerkeil
>>
>>
>>
>> * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC Member,
>> JSR 363 Spec Lead will present "JSR 363 - The Answer to Life Science and
>> the Internet of Everything"
>>
>>
>>
>> * JavaOne 2014: Sep 30, San Francisco, USA, Werner Keil, JCP EC Member,
>> JSR 354 EG Member will host "Java and Digital Currencies, Friend or FOE"
>>
>>
>>
>> * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC
>> Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class
>> DevOps", "JSR 363"
>>
>> * ApacheCon Europe: 17 Nov 2014, Budapest, Hungary. Werner Keil, JCP EC
>> Member, Apache DeviceMap Committer will present "Apache DeviceMap"
>>
>>
>>
>> * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany.
>> Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache
>> DeviceMap" (GER)
>>
>>
>>
>> On Sun, Sep 14, 2014 at 12:29 PM, Otávio Gonçalves de Santana <
>>
>>  wrote:
>>
>> Hi Guys.
>>
>> How is going?
>>
>>
>>
>> I believe we have a possible problem with nomeclature in
>>  AbstractQuantity's class, looking this example:
>>
>>
>>
>> Quantity<Length> metre = AbstractQuantity.of(10, SI.METRE);
>>
>> Quantity<Length> foot =  metre.to(US.FOOT);
>>
>>
>>
>> IMHO, Abstract* is not a good name to a factory, maybe just Measure, so
>> will:
>>
>>
>>
>> Quantity<Length> metre = Meansure.of(10, SI.METRE);
>>
>> Quantity<Length> foot =  metre.to(US.FOOT);
>>
>>
>>
>> WDYF?
>>
>>
>>
>> --
>>
>> Otávio Gonçalves de Santana
>>
>>
>>
>> blog:     http://otaviosantana.blogspot.com.br/
>>
>> twitter: http://twitter.com/otaviojava
>>
>> site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
>>
>> 55 (11) 98255-3513
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Otávio Gonçalves de Santana
>>
>>
>>
>> blog:     http://otaviosantana.blogspot.com.br/
>>
>> twitter: http://twitter.com/otaviojava
>>
>> site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
>>
>> 55 (11) 98255-3513
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Otávio Gonçalves de Santana
>>
>>
>>
>> blog:     http://otaviosantana.blogspot.com.br/
>>
>> twitter: http://twitter.com/otaviojava
>>
>> site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
>>
>> 55 (11) 98255-3513
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Otávio Gonçalves de Santana
>>
>>
>>
>> blog:     http://otaviosantana.blogspot.com.br/
>>
>> twitter: http://twitter.com/otaviojava
>>
>> site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
>>
>> 55 (11) 98255-3513
>>
>>
>>
>>
>>
>

GIF image

GIF image

GIF image

Attachment: 347.gif
Description: GIF image



Re: AbstractQuantity's class

(continued)

Re: AbstractQuantity's class

Werner Keil 09/14/2014

Re: AbstractQuantity's class

Otávio Gonçalves de Santana 09/14/2014

Re: AbstractQuantity's class

Werner Keil 09/14/2014

Re: AbstractQuantity's class

Otávio Gonçalves de Santana 09/14/2014

Re: AbstractQuantity's class

Werner Keil 09/14/2014

Re: AbstractQuantity's class

Otávio Gonçalves de Santana 09/15/2014

Re: AbstractQuantity's class

Leonardo Lima 09/15/2014

Re: AbstractQuantity's class

Werner Keil 09/15/2014

RE: AbstractQuantity's class

Legrand, Karen 09/15/2014

RE: AbstractQuantity's class

Otávio Gonçalves de Santana 09/15/2014

Re: AbstractQuantity's class

Werner Keil 09/15/2014

Re: AbstractQuantity's class

Otávio Gonçalves de Santana 09/15/2014

Re: AbstractQuantity's class

Werner Keil 09/15/2014

Re: AbstractQuantity's class

Jean-Marie Dautelle 09/15/2014

Re: AbstractQuantity's class

Otávio Gonçalves de Santana 09/15/2014

Re: AbstractQuantity's class

Werner Keil 09/15/2014

Re: AbstractQuantity's class

Werner Keil 09/15/2014

Re: AbstractQuantity's class

Jean-Marie Dautelle 09/16/2014

Re: AbstractQuantity's class

Werner Keil 09/16/2014

Re: AbstractQuantity's class

Otávio Gonçalves de Santana 09/17/2014

Re: AbstractQuantity's class

Werner Keil 09/17/2014
 
 
Close
loading
Please Confirm
Close