Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121804
MIME-Version: 1.0
References: <CAPzBOBN=vJKEXB8TxznngFS5LZKu7e+oXOYrmXXfQf0BdeNeRQ@mail.gmail.com>
In-Reply-To: <CAPzBOBN=vJKEXB8TxznngFS5LZKu7e+oXOYrmXXfQf0BdeNeRQ@mail.gmail.com>
Date: Fri, 24 Nov 2023 03:46:20 -0800
Message-ID: <CA+pig-+NjzGC1Bz=YZGKUO1hAa=2v8+ML5kTx9uZrju76=2oJA@mail.gmail.com>
To: Robert Landers <landers.robert@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC][Discussion] Why can constructors violate LSP?
From: mark@itafroma.com (Mark Trapp)

On Thu, Nov 23, 2023 at 12:31 Robert Landers <landers.robert@gmail.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?
>
> Robert Landers
> Software Engineer
> Utrecht NL

(Apologies: resending because I used the wrong email address to send
to the list)

Hi Robert,

Liskov and Wing explicitly exempted constructors in their original
paper describing the principle:
http://reports-archive.adm.cs.cmu.edu/anon/1999/CMU-CS-99-156.pdf

> 4.1 Type Specifications
>
> A type specification includes the following information:
>
> - The type's name
> - A description of the type's value space
> - A definition of the type's invariant and history properties
> - For each of the type's methods:
>     - Its name;
>     - Its signature including signaled exceptions;
>     - Its behavior in terms of pre-conditions and post-conditions.
>
> Note that the creators are missing. Omitting creators allows subtypes to =
provide different creators than their supertypes. In addition, omitting cre=
ators makes it easy for a type to have multiple implementations, allows new=
 creators to be added later, and re ects common usage: for example, Java in=
terfaces and virtual types provide no way for users to create objects of th=
e type.

(Creators is Liskov's word for constructors, which they later define
in the paper.)

Hope that helps.

- Mark Trapp