Re: [RFC] [Discussion] Add WHATWG compliant URL parsing API
| From: | Máté Kocsis | Date: | Tue, 25 Mar 2025 22:23:03 +0000 |
| Subject: | Re: [RFC] [Discussion] Add WHATWG compliant URL parsing API | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-126945@lists.php.net to get a copy of this message | ||
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é
>