Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121790
Date: Thu, 23 Nov 2023 21:27:00 +0000
To: internals@lists.php.net
User-Agent: K-9 Mail for Android
In-Reply-To: <CAPzBOBN=vJKEXB8TxznngFS5LZKu7e+oXOYrmXXfQf0BdeNeRQ@mail.gmail.com>
References: <CAPzBOBN=vJKEXB8TxznngFS5LZKu7e+oXOYrmXXfQf0BdeNeRQ@mail.gmail.com>
Message-ID: <DA623C11-DFE5-42C6-9307-701A7395D10E@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC][Discussion] Why can constructors violate LSP?
From: rowan.collins@gmail.com (Rowan Tommins)

On 23 November 2023 20:31:09 GMT, Robert Landers <landers=2Erobert@gmail=2E=
com> wrote:

>I'd like to propose an RFC to enforce the covariance of constructors
>(just like is done for other methods), to take effect in PHP 9, with a
>deprecation notice in 8=2E3=2Ex=2E

There's a lot more than visibility that is enforced on normal methods, but=
 isn't on constructors=2E For instance this is also valid:

class A {
    public function __construct(int $foo) {}
}
class B extends A {
    public function __construct(string $bar) {}
}

From=20a theoretical perspective, I think the argument is roughly that class=
es aren't first-class citizens that you can pass around, so substitutabilit=
y doesn't apply=2E You can't for instance write a function that explicitly =
depends on "a class definition inheriting from A", like this:

function foo(class<A> $class) {
     $instance =3D new $class(42);
}

You can certainly simulate such code with some strings and maybe a bit of =
reflection, but the language isn't going to make any guarantees about it=2E

I did just think of a counter-example, though, which is that "new static($=
param)" is allowed, even though there's no way to know if $param will be ac=
cepted by subclasses=2E Maybe it shouldn't be allowed?


From=20a practical point of view, it's often very useful to sub-class someth=
ing and provide a constructor with a different signature=2E Maybe your subc=
lass has additional dependencies; maybe it can hard-code or calculate some =
of the inputs to the parent constructor for a special case, etc=2E

A private constructor can be used in conjunction with static methods to si=
mulate multiple named constructors (createFromString, createFromRequest, et=
c)=2E Given the lack of other guarantees, there's no particular gain in pre=
venting that just because the parent class has a public constructor=2E

Regards,

--=20
Rowan Tommins
[IMSoP]