Comment on CSR 8251991: Hex formatting and parsing utility
Raffaello Giulietti
raffaello.giulietti at gmail.com
Mon Mar 29 21:07:26 UTC 2021
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
>
More information about the core-libs-dev
mailing list