Thanks, I noticed.
There are a couple of other methods that can be simplified, require a
couple of minutes to review and which don't have any impact on the API.
If you agree, I'll prepare a PR with all the changes and the bug
narrative for you to add to bugs.openjdk.org (I only have read access).
Greetings
Raffaello
On 2021-03-26 16:08, Roger Riggs wrote:
fyi, a PR to make the methods static.
https://git.openjdk.java.net/jdk/pull/3205
On 3/15/21 4:26 PM, Raffaello Giulietti wrote:
Hello,
I understand your points expressed in
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-October/070317.html
On the other hand, it kind of hurts when the javadoc spec implies that
the fromXXX() methods do not logically depend on the state and yet one
has to invoke them on some instance anyway.
As for HexFormat.of() to always return the same instance, you are of
course right in observing that this is out of place for value-based
classes. The intent was to describe a static-like idiom that would
deter programmers to rewrite their own static version of these methods.
Greetings
Raffaello
Hi,
The question about static vs instance methods was raised during the
review.
At the time, my rationale for the current API is summarized in this
email.
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-October/070317.html
It comes down to choosing one kind of consistency vs another.
I was/am looking for additional comments to weigh one or the other
alternative.
I did receive one offline comment in support of static methods on the
rationale of
convenience.
Regards, Roger
On 3/15/21 12:06 PM, Raffaello Giulietti wrote:
Hi,
the javadoc of most of the methods listed in my previous post below
reads:
"The delimiter, prefix, suffix, and uppercase parameters are not
used."
As these eventually constitute the whole state of an instance of
this final class and as the state is not involved, it is possible to
declare the methods as static.
If, for some reason, declaring the methods as static is not a
choice, the next best thing is to clarify that
* HexFormat.of() always returns the same instance and thus
* absent any other instance, the recommended idiom for invoking any
of the methods below is, for example,
HexFormat.of().isHexDigit('F')
(because there are almost no additional costs wrt static methods.)
Note that HexFormat is specified as a value based class and
any statement related to identity is out of place.
Incidentally, its generally discouraged and can cause a warning when
a static method is invoked using a reference.
But I don't see a reason why they should be non-static. Just oversight?
Greetings
Raffaello
On 2021-03-08 11:52, Raffaello Giulietti wrote:
Hello,
it appears that all of the following API methods in [1] can be
declared *static*, which makes them more useful in contexts where
there's no instance of HexFormat available or none is desired.
As 17 has not yet entered any formal phase, the change should be
harmless.
public boolean isHexDigit(int);
public int fromHexDigit(int);
public int fromHexDigits(java.lang.CharSequence);
public int fromHexDigits(java.lang.CharSequence, int, int);
public long fromHexDigitsToLong(java.lang.CharSequence);
public long fromHexDigitsToLong(java.lang.CharSequence, int, int);
Greetings
Raffaello
----
[1] https://bugs.openjdk.java.net/browse/JDK-8251991
