Use Advanced Search to search the entire archive.
[jsr363-experts] Re: Trivial formatting proposals
- From: Werner Keil <
>
- To: "
" <
>
- Subject: [jsr363-experts] Re: Trivial formatting proposals
- Date: Sat, 13 Dec 2014 16:16:43 +0100
That sounds like more than one JIRA task or improvement ticket[?]
Unit.getSymbol() should be locale neutral, keep in mind, Java ME Embedded
has no Locale, we just fixed a problem in the API recently[?]
So instead of Unit.getDisplaySymbol() or similar (like in
java.util.Currency) we have to try something more along the lines of JSR
354.
CurrencyUnit is also locale-neutral, at most via a CurrencyContext there
could be things like the country, etc. but the interface itself only
returns a language neutral code.
We might want to document that a bit further both in future versions of the
Spec past EDR and maybe JavaDoc.
Returing simply a UCUM code was a thought, but for most general purpose
apps getting something like [ft_us] instead of ft sounds a bit impractical.
For a vast majority of standard units UCUM "print" does however give a very
decent readable string, so for the RI we might also consider returning
that by default.
UCUM is locale agostic, and so should be most attributes of Unit. The UCUM
table contains a descriptive name (in English) which we may use (at the
moment mostly symbol is fully implemented) but for translations to other
languages, I guess the format package and its elements sounds best.
Adding toString() I believe, JSR 310 did that, while it's a method of every
Object, we could do this in places like Unit, too.
Werner
On Sat, Dec 13, 2014 at 1:05 PM, Martin Desruisseaux <
>
wrote:
>
>
Following are very trivial formatting proposals (no code change), but
>
maybe they could help a little bit the reading?
>
>
- In Quantity, make Javadoc a little bit more explicit about the fact
>
that value and unit are the 2 main properties of a quantity.
>
- In Quantity, move the getValue() and getUnit() methods first since
>
they are the main properties of a quantity.
>
- In Quantity, move multiply methods before divide methods.
>
- In SystemOfUnits, add javadoc to the getName() method.
>
- In Unit, there is a javadoc formatting problem in many methods (
>
getSystemUnit(), asType(Class), alternate(String), etc.)
>
- In Unit, the getName() and getSymbol() javadoc should clarify in
>
which locale they are displayed. Or maybe those methods should have a
>
Locale argument?
>
- In Unit, move inverse() after divide methods for consistency with
>
the Quantity interface.
>
- In Unit, move root after pow method for consistency with the
>
Dimension interface and with the usual pattern of placing the
>
"simpler" method first, and its inverse after (add - subtract, multiply -
>
divide).
>
- In Unit, move toString() as the last method for consistency with
>
common usage. This will also keep transform method close to the other
>
methods that create a new unit.
>
>
Martin
>
>
Attachment:
329.gif
Description: GIF image
Attachment:
347.gif
Description: GIF image