> On Mar 25, 2025, at 4:06 PM, Dennis Snell <[email protected]> wrote:
>
>
>> 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.
>
>
Just for fun I have tossed this into DeepSeek-R1 671B
> WHATWG URLs have two representations: one for humans and one for machines. The reason for
>having two is that URLs may have IDNA domains which are punycode encoded and there are security
>issues around showing that to huamns. For example, if a person reads "https://xn--google.com" they may assume that the domain
>belongs to Google, when in fact it points to "https://䕮䕵䕶䕱.com". You are a modern
>programming language designer working on a standard library to expose a URL parser and you want the
>interface of this library to educate developers on where to use the appropriate representation.
>Given a URL object $u of class URL, propose two methods for converting that URL to a string. The
>name of the methods should communicate their use, and when a developer searches for the right method
>to get the string form, they should not be presented with a non-prefixed and prefixed pair like
>toString() and toHumanString(). Instead, the methods names should form a kind of symmetric pair like
>toEncodedString() and toDisplayString(). Use your knowledge of WHATWG URL nuances, browser security
>issues, human developers making typical mistakes, and propose at least ten pairs of words that could
>be used for returning these two different representations.
A few of the ideas that it returned which stuck out were:
- toDataString() / toViewString() and getDataHost() / getViewHost()
- toSerializedString() / toReadableString() and getSerializedHost() / getReadableHost()
- toProcessingString() / toSafeDisplayString() and getProcessingHost() / getSafeDisplayHost()
After checking in the Gecko source code, I sadly only found helper methods which take a URL/URI and
transform them:
- prepareUrlForDisplay()
- unEscapeURIForUI()
Node seems to punt on this by providing URL.format() with a { unicode: boolean
} option. These all seem to miss the mark, in my opinion, because of how easy it is to assume
that toString() or .host is what you’re after.
Thanks for entertaining the extra follow-up here.
Warmly,
Dennis Snell