Hi Maté and all, > On Apr 27, 2025, at 16:47, Máté Kocsis <kocsismat...@gmail.com> wrote: > > Hi Tim, ... >> So it seems to be safer to use the naming without the `raw` and then in >> the documentation explain what happens with useful examples, just like >> the RFC already does. > > We discussed this off the list, and the recommendation made sense to me at > last.
I am glad to see it! * * * Removing the `raw()` methods from the Whatwg\Url class opens up another opportunity. The Rfc3986\Uri `raw()` methods present a departure from existing userland expectations when working with URIs. No existing URI package that I'm aware of retains the normalized values as their "main" values; the values are generally retained-as-given (i.e. "raw"). Nor do they afford getting two versions of the retained values (one raw, one normalized). This might be solved by renaming the Rfc3986\Uri methods so that the "main" methods return the raw values, and the alternative methods return the normalized versions. For example, getPath() would become getNormalizedPath(), and getRawPath() would become getPath(). But that's pretty verbose, and on considering it further, I think I think there are two classes combined inside Rfc3986\Uri. Proposal: Instead of a single Rfc3986\Uri class that tries to hold *both* raw *and* normalized values and logic at the same time, introduce a NormalizedUri class to operate with normalized values, and treat the current Uri class as operating with raw values. That would, among other things: - fulfill existing userland expectations; - eliminate the getRaw() methods; - replace the toString()/toRawString() with a single idiomatic __toString() in each class; - move normalization logic into the NormalizedUri class. Optionally, there could be one additional method one or both classes, toNormalizedUri(), to create and return a normalized instance. For Uri the return would be a new NormalizedUri; for NormalizedUri, the return would either be itself ($this) or a clone of itself. If the RFC pursues that approach, it will also lend itself to either an abstract they each extend or (preferably) an interface they each implement. If an interface, I opine it should be called Uri; the current Uri class might become RawUri (with NormalizedUri not needing a rename). Thoughts? -- pmj
