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é
