Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119589
MIME-Version: 1.0
References: <CABAhh3Ed1uwS8bY75Rz_4FkhU4Bq7Fx0TexnLgQQcvhygcTgvQ@mail.gmail.com>
 <CAAwdEzDH_NoRcNwWh1MULqNAHu6g0S0oi8j2XtgZOKWYA+fPwQ@mail.gmail.com>
In-Reply-To: <CAAwdEzDH_NoRcNwWh1MULqNAHu6g0S0oi8j2XtgZOKWYA+fPwQ@mail.gmail.com>
Date: Tue, 21 Feb 2023 15:30:38 +0200
Message-ID: <CABAhh3HpcuHPBKwd+8_-_GFy2gVy4-s9_+6ytU2ijZQKF4RD=w@mail.gmail.com>
To: =?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= <drealecs@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Class Re-implementation Mechanism
From: someniatko@gmail.com (someniatko)

> This sounds interesting but it breaks some expectations.
>
> Interesting because you can have any class act as an interface for other classes with the interface being built up of any public properties or method that exists on that class.

In my original suggestion, it's not like any class, but only those you
specifically mark as `class interface`, not just `class`. Closer to
the end of my idea I also suggest that maybe it's worth it to allow
implementing, like interfaces, ANY classes, not only those
specifically marked with the new syntax, but this indeed brings up
some issues.


> Ok, maybe not any class but just a final class.

I see no issue there of allowing to reimplement the interface of a
non-final class. This still is better than extending from it IMO. But
we _probably_ should prohibit it from abstract classes.


> And also maybe just a final class that doesn't yet implement an interface.

Also, here is no conflict as well. When reimplementing the interface
of the class, you can treat it as a normal interface - which can
extend from other interfaces.


> The expectation it breaks is that if you have a final class, whenever you use it, you expect some specific implementation exists on it.
> And this would break the expectation and in real life someone might pass a totally different implementation.
> Will not break generic LSP but still will break some expectations.

That's why a new syntax is brought up. This expectation might indeed
break if we allow to reimplement any existing final class, instead of
requiring a manual opt-in.

(sorry, this email is sent to you the second time, Alexandru, because
I forgot to reply to the maillist as well)

Regards,
Illia / somenitko