> On Mar 25, 2025, at 3:23 PM, Máté Kocsis <[email protected]> wrote:
>
>
> Hi Dennis,
>
>
>> I am myself also a bit lost on the countless names that I tried out in the implementation,
>> but I think I had toHumanFriendlyString() and toDisplayFriendlyString() methods at some point. These
>> then ended up being toString() and toDisplayString() after some iterations. I would be ok with
>> renaming getHost() and toString() so that their names suggest they don't use IDNA, but
>> I'd clearly need a good enough suggestion, since neither "MachineFriendly", nor
>> "NonDisplayable" sound like the best alternative for me. I was also considering using
>> getIdnaHost() and toIdnaString(), but I realized these are the worst looking names I have come up
>> with so far.
>>
>>
>>
>
> What about getPunycodeHost(), getUnicodeHost(), toPunycodeString(), toUnicodeString()? Or
> getAsciiHost() and toAsciiString() may also work. These are the best names I managed to come up with
> so far.
>
>
> In the meantime, I renamed RFC 3986's toString() methods too according to another
> suggestion:
> - toString() became toRawString()
> - toNormalizedString() became toString()
>
>
> The new names mirror exactly what their getter counterparts do.
>
>
> Máté
>
>
Hi Máté,
I’ve been pondering these names for the past week and a half and I couldn’t think of anything,
but at first glance I like getUnicodeHost() and getAsciiHost(). These communicate a little bit the
nuance, though they aren’t totally in-your-face (which in this case I wish there were a more
obvious pair that is).
Other pairs I was toying with but don’t like are:
- getPrintHost() / getDataHost()
- getDisplayHost() / getAPIHost()
- getDisplayHost() / getEncodedHost()
- getDisplayHost() / getEscapedHost()
(the same pairs would apply to the other methods, like toDisplayString() / toEncodedString())
This seems to be taking a lot of effort and time, but thank you still for engaging with it —
naming is hard! But it’s worth it.