Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121808
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> <CAPzBOBMvY8Ur3BhHSBfHsZhK8b4TBHED2FLwJRZ4+HmmiRdPEQ@mail.gmail.com>
 <CADK1yXJdGNuWB86=T4fWuhkfv1=7v+MrCr-ep18DHuiiY-qB2g@mail.gmail.com>
In-Reply-To: <CADK1yXJdGNuWB86=T4fWuhkfv1=7v+MrCr-ep18DHuiiY-qB2g@mail.gmail.com>
Date: Fri, 24 Nov 2023 15:40:42 +0100
Message-ID: <CAPzBOBNLG-10_U+80yf+9zVcYwJNzVJXEZO6Uhh1dmJhsqrffQ@mail.gmail.com>
To: Deleu <deleugyn@gmail.com>
Cc: Mike Schinkel <mike@newclarity.net>, 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 2:30=E2=80=AFPM Deleu <deleugyn@gmail.com> wrote:
>>
>> 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.
>
>
> Hey Robert, as we've established we may not agree on this subject and I r=
eally don't want to sound like I want to convince you, so feel free to igno=
re my email or reply that this isn't helping. My goal here is merely to try=
 and address what I think the error is in case it gives you some clarity.
> -----
>
> In this snippet, you're using `new static()` which again is something PHP=
-specific and not 100% OOP definition. PHP has a friendly syntax to help yo=
u figure out what the class name is during runtime, this again is metadata.=
 With these tools, I believe you are able to accomplish what you want by ex=
plicitly adding the constructor to your public API.
>
> ```
> abstract class Template
> {
>     abstract public function __construct(string $explicitlyDefinitionOfPu=
blicAPI);
> }
>
> class A extends Template {
>     public function __construct(string|null $ignore) {}
>
>     final public static function foo()
>     {
>         return new static('parameter defined from A');
>     }
> }
>
> class B extends A {
>     public function __construct(public string $name) {}
> }
>
> $b =3D B::foo('test');
> var_dump($b->name);
> ```
>
> Let's break this down. The `Template` class uses the Abstract Template pa=
ttern to define a public interface of the inheritance chain. As such, it of=
fers the ability to opt-in to something that isn't standard: The Constructo=
r method being part of a class Public API.
>
> Two things happen from this. We are forced to implement a constructor on =
class A otherwise we get:
> Fatal error: Class A contains 1 abstract method and must therefore be dec=
lared abstract or implement the remaining methods (Template::__construct) i=
n /in/7qX9j on line 8
>
> And we inherit the Constructor from A in B or we need to override it. My =
conclusion here is that 1) if you know what you're doing and 2) you want to=
 make a constructor's object part of your public API, and therefore, respec=
t LSP, you are free to do so.
>
> - Why shouldn't this be the default behavior in PHP?
> Let's ignore for a second 28 years of breaking change and focus on the OO=
P principle
>
>
> ```
> <?php
>
> abstract class Queue
> {
>
>     final public function serialize(array $message): string
>     {
>         return json_encode($message);
>     }
>
>     abstract public function push(array $message): void;
> }
>
> final class SqsQueue extends Queue
> {
>     public function __constructor(private \Aws\Sqs\Client $client, privat=
e string $queue) {}
>
>     public function push(array $message): void
>     {
>         $data =3D $this->serialize($message);
>
>         $client->sendMessage([
>             'QueueUrl' =3D> $this->queue,
>             'Message' =3D> $data,
>         ]);
>     }
> }
>
> final class RedisQueue extends Queue
> {
>     public function __constructor(private \Illuminate\Redis\Connectors\Ph=
pRedisConnector $connector, private array $configuration, private array $op=
tions) {}
>
>     public function push(array $message): void
>     {
>         $connection =3D $this->connector->connect($this->configuration, $=
this->options);
>
>         $data =3D $this->serialize($message);
>
>         $command =3D "redis.call('rpush', KEYS[1], ARGV[1])";
>
>         $connection->eval($command, 1, 'queues:my-queue', $data);
>     }
> }
> ```
>
> This is a text-book case of LSP. A class that expects to receive a `Queue=
` object can freely use `push()` in a consistent and predictable manner, al=
lowing substitution as it sees fit. The object constructor is exempt from L=
SP because it is the implementation detail of a particular class.
> RedisQueue needs to be able to communicate with Redis in order to provide=
 a queueing capability.
> SqsQueue needs to be able to communicate with AWS SQS in order to provide=
 a queuing capability.
>
> They have different dependencies/configurations and they wouldn't be able=
 to perform their capabilities if the language forced their constructor to =
follow a single compatible signature.
>
> -----
>
> In conclusion, I think PHP has the best of both worlds. We get little hel=
pers to accommodate how OOP looks like in a dynamic script language (i.e. n=
ew static()) and we have a fully functioning LSP that allows you to take ad=
vantage of it however you see fit. The Queue example goes to show why havin=
g a constructor as part of the public API of a class hierarchy would be ext=
remely bad, but PHP is nice enough to let you opt-in to it if you have reas=
ons to force a class hierarchy to have a single dependency signature.
>
>
> --
> Marco Deleu

Hello internals,

I won't be pursuing this as an RFC. It seems either an abstract class
or interface can force users to obey LSP, but it is purely opt-in. It
strikes a good balance, but does create some surprises when someone
comes along with a bug they wrote themselves into without realizing
it.

Thank you all for your discussion!

> Let's ignore for a second 28 years of breaking change and focus on the OO=
P principle

I wish more people had that attitude on this list. :D I'm of the
opinion that you first decide to do something, then figure out how to
make it backward-compatible and maintain it. Take annotations, for
example, it was wanted, and then it was figured out how to (cleverly)
make them backward compatible. If people had gotten hung up on
backward compatibility or maintenance from the beginning, I doubt it
would have ever made it past that point. Now, annotations are
increasingly useful in PHP, from describing how to serialize an
object, to validations, to guards.

Robert Landers
Software Engineer
Utrecht NL