> On Mar 25, 2025, at 3:23 PM, Máté Kocsis <kocsismat...@gmail.com> 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.
