On 10/12/20 7:08 PM, Marcono1234 wrote:
src/java.base/share/classes/java/util/HexFormat.java line 836:
834: * otherwise {@code false}
835: */
836: public boolean isHexDigit(int ch) {
Should this method be `static`? Or otherwise should it consider the
`uppercase()` setting?
(Same for `fromHexDigit` and all the other subsequent methods)
These methods being instance methods is likely pretty confusing because they
are unrelated to the HexFormat instance
and makes using them cumbersome because the user has to create a HexFormat
instance first.
All of the functions that convert binary to strings are formatting,
though a simpler term could be used.
As for static vs instance methods, there are a number of competing
interests.
- Asymmetry between toHex and fromHex methods if the former were
instance and the later were static methods.
- The HexFormat context is needed for the prefix, suffix, and
delimiter for the byte array versions vs the primitive value versions.
- If the fromHex methods are static, and the toHex methods remain
instance methods due to the uppercase/lowercase paramter, that's another
kind of asymmetry.
- Invoking and imports for static methods pushes the code to take on a
different shape that is less appealing when mixed. (IMHO)
As the design was maturing, the choice was to keep all of the methods
related to the parameters via the HexFormat instance.
Though there are no forseen future enhancments, keeping all the methods
as instance methods would allow possible extensions to consistently
apply to all formatting and parsing methods.
Are there other considerations that should be taken into account?
Regards, Roger
