Re: [RFC] [Discussion] Add WHATWG compliant URL parsing API
| From: | Marco Pivetta | Date: | Mon, 24 Feb 2025 13:57:32 +0000 |
| Subject: | Re: [RFC] [Discussion] Add WHATWG compliant URL parsing API | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-126492@lists.php.net to get a copy of this message | ||
On Mon, 24 Feb 2025 at 14:45, Nicolas Grekas <nicolas.grekas+php@gmail.com>
wrote:
>
>
> Am 2025-02-24 12:08, schrieb Nicolas Grekas:
>> > The situation I'm telling about is when one will accept an argument
>> > described as
>> > function (\Uri\WhatWg\Url $url)
>> >
>> > If the Url class is final, this signature means only one possible
>> > implementation can ever be passed: the native one. Composition cannot
>> > be
>> > achieve because there's no type to compose.
>>
>> Yes, that's the point: The behavior and the type are intimately tied
>> together. The Uri/Url classes are representing values, not services. You
>> wouldn't extend an int either. For DateTimeImmutable inheritance being
>> legal causes a ton of needless bugs (especially around serialization
>> behavior).
>>
>
> DatetimeImmutable is a good example of community-proven usefulness for
> inheritance:
> the carbon package has a huge success because it does add a ton of nice
> helpers (that are better maintained in userland) while still providing
> compatibility with functions that accept the native type.
>
> The fact that the native implementation had bugs when inheritance was used
> doesn't mean inheritance is a problem. It's just bugs that need to be
> fixed. Conceptually nothing makes those bugs inevitable.
>
> Closing the class would have hindered community-innovation. The same
> applies here.
>
>
TBH, data-point from someone that spends time removing Carbon usages here
:-P
The
DateTimeImmutable type should've been final from the start: it is
trivial to declare a userland interface, and then use the
DateTimeImmutable type as an implementation detail of a userland-provided
interface.
PSR-7, for example, will benefit greatly from this new RFC, without ever
having to expose the underlying value type to userland.
Inheritance is a tool to be used when there is LSP-compliant divergence
from the original type, and here, the PHP RFC aims at modeling something
that doesn't have alternative implementations: it's closed for
modification, and that's good.
Marco Pivetta
https://mastodon.social/@ocramius
https://ocramius.github.io/