Should we deprecate MetricPrefix.DEKA()?

[keilw]

While extending the prefixes based on #243 I noticed, we always used the US-spelled DEKA() despite an otherwise British naming DECA() that also correlates with the BIPM. I decided to immediately fix the enum entry because it would be rather weird to have both (and break tests etc. based on the number of enum entries, because they would be 25 instead of 24), but keep the (far wider used, and until MR2 only one mentioned in the JavaDoc) convenience method in both the BIPM/English and US version.

The question is, do we keep both or should we deprecate DEKA() to be removed from a future version of the API?

[keilw]

@dautelle, @otaviojava or @desruisseaux, any thoughts? Given the NIST uses deka I'm inclined to keep both (convenience) methods.

[desruisseaux]

The American spelling is of course very widely used, but despite that the international organization for standards ISO uses British spelling in their standards. BIPM does the same apparently. I have a slight preference for using only one spelling, which would be the one of those standard organizations, because convenience can sometime be complications (e.g. a developer needs to search for all usages of deca, does a search but forget to check also for deka). But I don't think that it is a big issue.

[dautelle]

Agree, let's keep it :)

On Tue, May 9, 2023 at 5:53 PM Werner Keil @.***> wrote:

@dautelle https://github.com/dautelle, @otaviojava https://github.com/otaviojava or @desruisseaux https://github.com/desruisseaux, any thoughts? Given the NIST https://www.nist.gov/pml/special-publication-811/nist-guide-si-chapter-4-two-classes-si-units-and-si-prefixes uses deka I'm inclined to keep both methods.

— Reply to this email directly, view it on GitHub https://github.com/unitsofmeasurement/unit-api/issues/250#issuecomment-1540448139, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPH2KQLJI6UEHJSYNV4IH3XFJSAZANCNFSM6AAAAAAWRQHPTQ . You are receiving this because you were mentioned.Message ID: @.***>

[keilw]

Thanks for your input. As the method is only a "convenience method" or the old style of using the prefix (before Unit.prefix(Prefix)) there seems no harm in having both, while the enum had to be renamed in a slightly harder change, but as the methods were around longer that should be acceptable and break few or no code.