Use Advanced Search to search the entire archive.
Re: Remove "generic" multiply/divide operations from Quantity
- From: Werner Keil <
>
- To:
- Subject: Re: Remove "generic" multiply/divide operations from Quantity
- Date: Fri, 17 Oct 2014 12:39:32 +0200
Beside, the JDK is full of lies and semantic inconsistensies;-/
java.util.Calendar as awkward as its mutable behavior might be applied
semantics and naming conventions much more correctly than
java.util.concurrent.TimeUnit;-)
http://stackoverflow.com/questions/1335959/singular-or-plural-for-enumerations
The latter was introduced with Java 5 after enums existed, but clearly
violates pretty much every common sense for naming enums not to mention a
Unit rather than a "Collection" of them.
JSR 310 in its early form I reviewed (as one of few EC Members doing so;-)
used Concurrent TimeUnit directly. Hence, while some things got renamed,
e.g. Time to Temporal the mistake of TimeUnit (using Singular for the type,
but Plural for its values) was bluntly copied. Just like the entire
DateFormat with its pattern strings was copied rather than reused. Creating
anothe of many redundancies in 310.
Last but not least, TemporalAmount should have been called TemporalMap,
because all it really does is mimick and clone java.util.Map with its get()
method.
A true Amount would look like the ones in JScience, OUMo or JSR 354. That
may allow e.g. a MonetaryQuery or other API constructs (all and more like
TemporalField, 310 got redundantly and usually competing rather than
synergetic;-O) to gather information like "How many notes or coins of each
type do I have in my pocket?", but MonetaryAmount has a straight
getNumber() method rather than get(Coin) ;-)
There is more, e.g. Java SE 9 has plans to offer factory methods like of()
to an interface like Map, List or Set as opposed to concrete classes.
Among few libraries thrown into OpenJDK 310 here insists on concrete, final
classes, while a factory like of() exists (in many redundant variations
like ofNanosAndMillis() ;-/) while Collection API seriously considers that
factory on the interface, since SE 8 a static method is possible there.
However, what would the default be, if you define List.of() to take e.g. an
array of things to add?
ArrayList, LinkedList,...?
That goes exactly where AbstractQuantity.of() was, at least in RI and
Java7/ME8 that's the closest we can get, from SE 8 in theory even Quantity
could have that static method like that;-)
@Otavio, please let's talk about that separately, if JDK prefers of() to an
abstract type (including interfaces) we should consider going back there,
too and avoid the "Quantities" helper class;-)
Werner