Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121799
MIME-Version: 1.0
References: <CAPzBOBN=vJKEXB8TxznngFS5LZKu7e+oXOYrmXXfQf0BdeNeRQ@mail.gmail.com>
 <CADK1yXL02Rjbz87c_cNq=k2eqjFdLKePE30yWiZpxNGX4DH-nw@mail.gmail.com>
 <CAPzBOBORjT4f1T5w_1z3po3pa2hTg6TpRfkdj29oFbLFqiGrCg@mail.gmail.com> <A45B9DB4-1D65-494B-86DC-4BC0C52C988E@newclarity.net>
In-Reply-To: <A45B9DB4-1D65-494B-86DC-4BC0C52C988E@newclarity.net>
Date: Fri, 24 Nov 2023 11:06:26 +0100
Message-ID: <CAPzBOBMvY8Ur3BhHSBfHsZhK8b4TBHED2FLwJRZ4+HmmiRdPEQ@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
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 Fri, Nov 24, 2023 at 5:06=E2=80=AFAM Mike Schinkel <mike@newclarity.net>=
 wrote:
>
>
>
> On Nov 23, 2023, at 4:50 PM, Robert Landers <landers.robert@gmail.com> wr=
ote:
>
> On Thu, Nov 23, 2023 at 10:30=E2=80=AFPM Deleu <deleugyn@gmail.com> wrote=
:
>
>
> 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.
>
>
> What Marco said pretty much mirrors the answer in Software Engineering SE=
:
>
> https://softwareengineering.stackexchange.com/a/270738/9114
>
> As if probably obvious now, when you are using a variable containing a cl=
ass name to instantiate a class you are actually not using OOP, you are usi=
ng the text expansion capabilities of PHP. The fact that it appears to be s=
imilar to a method call is just likely coincidence,
>
> Now if classes were first class objects in PHP, then there might be an ar=
gument, but alas, they are not.
>
> Anyway, I always addressed the problem you are running into by defining a=
 `make_new()` static method.  Here's what your example might look after an =
initial refactor:
>
> class P {
>     public $msg;
>     function __construct($msg){
>         $this->msg =3D $msg;
>     }
> }
> class C extends P {
>     static function make_new($props){
>         return new C($props["msg"]);
>     }
> }
>
> $class =3D "C";
>
> if(is_subclass_of($class, P::class)) {
>    $example =3D $class::make_new( ["msg"=3D>"world"] );
>    print_r($example);
> }
>
> Of course, getting it to production code will take a lot more, like you c=
an see here (although this code has now been update for probably five years=
 since I am no longer coding in PHP professionally):
>
> https://github.com/search?q=3Drepo%3Awplib%2Fwplib%20make_new&type=3Dcode
>
> And if you are dealing with 3rd party classes, you'll need to write wrapp=
er classes.
>
> Hope this helps.
>
> -Mike
>

Hey Mike,

Using a static method to enforce LSP when it should have been enforced
in the first place, merely proves my point that it violates LSP. I
don't know how else to spell it out, I guess we can try this one next:

class A {
    final public static function foo() {
        return new static();
    }
}

class B extends A {
    public function __construct(private string $name) {}
}

$a =3D B::foo();

It just plainly violates LSP and you can't write safe code that
touches constructors. I don't know how else to spell this out.