Use Advanced Search to search the entire archive.
Re: Remove "generic" multiply/divide operations from Quantity
- From: Martin Desruisseaux <
>
- To:
- Subject: Re: Remove "generic" multiply/divide operations from Quantity
- Date: Sat, 18 Oct 2014 18:49:12 +0900
- Organization: Geomatys
Le 17/10/14 19:39, Werner Keil a écrit :
>
>
Beside, the JDK is full of lies and semantic inconsistensies;-/
>
Maybe, but all the examples that you gave below are about naming
conventions. None of them are *logically* wrong. By "logical" I means
the mathematical sense, not intuition. This is very different from
UNITSOFMEASUREMENT-62 which is wrong, not in my opinion but under the
laws of logic.
Martin
>
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
>