Hi Larry and everyone who took part in the final vs non-final debate,
Thought: make the class non-final, but all of the defined methods final,
> and any internal data properties private. That way we know that a child
> class cannot break any of the existing guarantees, but can still add
> convenience methods or static method constructors on top of the existing
> API, without the need for an interface and a very verbose composing class..
>
I was thinking about this a lot, hesitating a lot on all the possibilities.
At last, I went with final classes. I know this is disappointing for
everyone who wanted to have an unlocked implementation,
and I am still sympathetic for providing some kind of extension point. I
synthesized my thoughts in a very lengthy section:
https://wiki.php.net/rfc/url_parsing_api#why_should_the_uri_rfc3986_uri_and_the_uri_whatwg_url_classes_be_final
so please read my full reasoning there.
TLDR: First of all, let me clarify that I want to open the API as soon as
the API becomes mature enough. However, based on the heated debate, we
would surely need a lor more time to find the best solution that won't have
unforeseen surprises. Since the final vs non-final question is a very small
(but important) detail of the proposal, I would like to discuss it on its
own, without affecting the whole work, and without risking to meet the
deadline of PHP 8.5. I really hope that this decision will give back the
focus on the most essential parts of the proposal that cannot be changed
(or only with a lot of difficulties) once the feature goes live: I mostly
think about the percent encoding/decoding related behavior, just to name
one thing.
Máté