Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121792
MIME-Version: 1.0
References: <CAPzBOBN=vJKEXB8TxznngFS5LZKu7e+oXOYrmXXfQf0BdeNeRQ@mail.gmail.com>
 <CADK1yXL02Rjbz87c_cNq=k2eqjFdLKePE30yWiZpxNGX4DH-nw@mail.gmail.com>
In-Reply-To: <CADK1yXL02Rjbz87c_cNq=k2eqjFdLKePE30yWiZpxNGX4DH-nw@mail.gmail.com>
Date: Thu, 23 Nov 2023 22:50:18 +0100
Message-ID: <CAPzBOBORjT4f1T5w_1z3po3pa2hTg6TpRfkdj29oFbLFqiGrCg@mail.gmail.com>
To: Deleu <deleugyn@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC][Discussion] Why can constructors violate LSP?
From: landers.robert@gmail.com (Robert Landers)

On Thu, Nov 23, 2023 at 10:30=E2=80=AFPM Deleu <deleugyn@gmail.com> wrote:
>
>
>
> On Thu, Nov 23, 2023 at 5:31=E2=80=AFPM Robert Landers <landers.robert@gm=
ail.com> wrote:
>>
>> Hello Internals,
>>
>> As you may know, an inherited method cannot reduce the visibility of
>> an overridden method. For example, this results in a fatal error
>> during compilation:
>>
>> class P {
>>     public function hello($name =3D 'world') {
>>         echo "hello $name\n";
>>     }
>> }
>>
>> class C extends P {
>>     private function hello($name =3D 'world') {
>>         parent::hello($name);
>>         echo "goodbye $name\n";
>>     }
>> }
>>
>> However, we can make certain methods private anyway, namely,
>> constructors (I haven't gone hunting for other built-in methods yet).
>> This is perfectly allowed:
>>
>> class P {
>>     public function __construct($name =3D 'waldo') {
>>         echo "hello $name\n";
>>     }
>> }
>>
>> class C extends P {
>>     private function __construct($name =3D 'world') {
>>         parent::__construct($name);
>>         echo "goodbye $name\n";
>>     }
>> }
>>
>> To my somewhat trained eye, this appears to violate the Liskov
>> Substitution Principle, for example, this now can have hidden errors:
>>
>> function create(P $class) {
>>     return new (get_class($class))();
>> }
>>
>> proven by:
>>
>> $c =3D (new ReflectionClass(C::class))
>>   ->newInstanceWithoutConstructor();
>>
>> create($c);
>>
>> Even though we thought we knew that the constructor was declared public.
>>
>> 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.3.x.
>>
>> I'm more than happy to implement it.
>>
>> Does anyone feel strongly about this one way or the other?
>
>
> Constructors are an implementation detail of a specialized class and as s=
uch they're not subject to LSP because the goal of LSP is to be able to mak=
e sure that any object of a given type hierarchy can be used to accomplish =
a certain behavior. If you take a step back from PHP's dynamic nature and t=
hink about LSP from a more pure type system, the fact you're expecting an o=
bject of type C, but then you completely disregard everything about the obj=
ect itself and dive into it's metadata to build another object, that's the =
moment you're no longer playing by the rules of OOP. It's like those mathem=
atical equations that prove that 1 =3D 2, they all have one thing in common=
: they end up dividing by 0 at some point.
>
> OOP here dictates that you should reach for patterns like Builder, Abstra=
ct Factory or similar. That way you constraint yourself to the rules of OOP=
 and you won't get weird outcomes.
>
> From another point of view, when a type is expected by a function or meth=
od, all we can expect from it is whatever was defined as the blueprint (cla=
ss/interface) of that object and the __construct() is a special method that=
 is not assumed to be part of that blueprint because it's not reasonable to=
 do `$object->__construct();` after receiving an object. As such, a constru=
ctor cannot break LSP because the constructor is not part of the object's A=
PI from a "receptor" point of view.
>
> I don't have a vote so take my opinion with a bucket of salt, but if I co=
uld I would definitely vote against such RFC.
>
>
> --
> Marco Deleu

Thanks Marco,

That's an interesting perspective and one I would agree with for the
most part, especially if you take my illustration at face value. Where
it gets weird/breaks down is when you have a class-string, that you
assert is the correct type, and then try to instantiate it:

// from somewhere
$class =3D "C";

if(is_subclass_of($class, P::class)) {
    $example =3D new $class("world");
}

If PHP didn't offer these built-in methods, then I would fully agree
with you, but it does, which puts it into a weird position where
sometimes a class is substitutable, and in this one special case, it
is not.

Robert Landers
Software Engineer
Utrecht NL