[RFC] [Discussion] Add WHATWG compliant URL parsing API

On 28/06/2024 22:35, Niels Dossche wrote:

• Why did you choose UrlParser to be a "static" class?
  Because "static class" is the hip new cool ;)

Bilge
I would argue that for 90%+ of cases, static userland classes are used because of (a) autoloading and (b) the ability to use private/protected methods.

Neither of those apply to a php extension.

I agree with the others, the static parser class is weird. Either put the static methods on the url class, or make the parser an instance with options.

No objection. I was only kidding :)

Cheers, Bilge

Hi Stephen,

I agree with the others, the static parser class is weird. Either put the

static methods on the url class, or make the parser an instance with
options.

Yes, I was sure that many people would find the signature of the parser
weird, and I can totally understand it. Since I
don't have hard feelings about any of the approaches, I'll try to find out
what way the proposal should be changed.
For the record, let me repeat my explanation about the current design
choice that I expressed in my reply to Niels:

... one of my major design goals was to make the UrlParser class to be

extendable and configurable (e.g. via an "engine" property similar to what
Random/Randomizer has). Of course, UrlParser
doesn't support any of this yet, but at least the possibility is there for
followup RFCs due to the class being final.

Since I knew it would be an overkill to require instantiating an UrlParser

instance for a task which is stateless (URL parsing),
finally I settled on using static methods for the purpose. Later, if the
need arises, the static methods could be converted to
non-static ones with minimal BC impact.

Regards,
Máté