Comment on CSR 8251991: Hex formatting and parsing utility

[Roger Riggs]

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