Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

On 29 Jun 2024, at 06:03, Bilge <bilge@scriptfusion.com> wrote:

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 :wink:

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.

Cheers

Stephen

On 29/06/2024 10:31, Stephen Reay wrote:

On 29 Jun 2024, at 06:03, Bilge<bilge@scriptfusion.com> wrote:

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 :wink:

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 :slight_smile:

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é