Comment on CSR 8251991: Hex formatting and parsing utility

[Raffaello Giulietti]

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
>