Use Advanced Search to search the entire archive.
Re: AbstractQuantity's class
- From: Jean-Marie Dautelle <
>
- To:
- Subject: Re: AbstractQuantity's class
- Date: Mon, 15 Sep 2014 23:40:18 +0200
Hi All,
Indeed, JScience use Amount but with a different semantics (using that same
name would create for me a headache due to name clashing).
It should be noted that Amount has to be a class (not an interface) in
order to provide static factory method (Java 7).
Usually (at least in JScience), you will have something like Amount
(interface) and Amounts with terminating s for the class holding static
factory method to produce Amount instances.
But since you intend to return Quantity types, I would suggest using
Quantities.of(100d, SI.METRE) - That would be consistent with standard
practices.
Best regards,
Jean-Marie.
On Mon, Sep 15, 2014 at 9:51 PM, Werner Keil
<
>
wrote:
>
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
>
>>
>
>>
>
>>
>
>>
>
>>
>
>
>
--
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:
347.gif
Description: GIF image