Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119587
MIME-Version: 1.0
References: <CABAhh3Ed1uwS8bY75Rz_4FkhU4Bq7Fx0TexnLgQQcvhygcTgvQ@mail.gmail.com>
In-Reply-To: <CABAhh3Ed1uwS8bY75Rz_4FkhU4Bq7Fx0TexnLgQQcvhygcTgvQ@mail.gmail.com>
Date: Tue, 21 Feb 2023 15:18:52 +0200
Message-ID: <CAAwdEzDH_NoRcNwWh1MULqNAHu6g0S0oi8j2XtgZOKWYA+fPwQ@mail.gmail.com>
To: someniatko <someniatko@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000faa13005f5359f5b"
Subject: Re: [PHP-DEV] Class Re-implementation Mechanism
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--000000000000faa13005f5359f5b
Content-Type: text/plain; charset="UTF-8"

Hi Someniatko,

On Tue, Feb 21, 2023 at 1:52 PM someniatko <someniatko@gmail.com> wrote:

> Hi again, internals
>
> My marathon of some crazy ideas continues :D, with less crazy one this
> time.
>
>
> ## Idea
>
> Allow "reimplementing" the non-static public API (that is public
> properties and methods, excluding constructor) of a class by other
> classes like this:
>
> ```php
> final class interface A {
>     public string $s;
>
>     public function __construct(string $s) { $this->s = $s; }
>
>     public static function fromInt(int $i): self { return new
> self((string) $i); }
>
>     public function foo(): int { return 42; }
> }
>
> final class B implements A {
>     public string $s = 'hello';
>
>     public function foo(): int { return 69; }
> }
>
> function usesA(A $param): void {}
>
> usesA(new B); // this works
> ```
>
>
> ## Explanation
>
> Consider there is a class like this:
>
> ```php
> final class Service {
>     public function __construct(private SomeDependency $dependency) {}
>     // ...
> }
>
> final class SomeDependency {
>     // ...
> }
> ```
>
> We want to write some tests for the Service class, but we don't want
> to use a real SomeDependency instance
> during tests. A common approach is to either extract an interface
> (JUST to make it testable), or to drop the
> `final` keyword and allow extending the class.
>
> Both approaches have their flaws:
>  - extracting an interface unnecessarily complicates the system, where
> only one "real" implementation of an interface is assumed.
>  - dropping the `final` keyword allows for the rabbit-hole of
> inheritance abuse, like greatly described in this article:
> https://front-line-php.com/object-oriented
>
> I believe I came up with a better idea: what if we could leave both
> benefits of prohibiting the inheritance abuse and also allow not to
> clutter our namespace with excess entities like interfaces? I hereby
> suggest to combine the responsibilities of a class and an interface
> into one thing like that:
>
> ```php
> final class interface C {}
> final class D implements C {}
> ```
>
> Now other classes can "implement" this class as well. Introduction of
> the new syntax (`class interface`) also solves BC problem - if you
> want to forbid your classes to be reimplemented whatsoever, you can
> still stick to the `final class` syntax. Although it is also possible
> to allow "reimplementing" ANY class, then new syntax is not needed -
> but some library writers like Marco Pivetta could be sad about that I
> suppose.
>
> Soo..., what do you think? Could this be a valuable addition to the
> language?
>

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.
Ok, maybe not any class but just a final class. And also maybe just a final
class that doesn't yet implement an interface.

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.



I believe other options should be followed that are more straightforward:

If it's your internal code not shared with others, you can easily extract
an interface at any point where you need to inject another instance (when
testing).
Also, if it's internal code, you can just not mark the class as final.

If it's a library code you use or share with others, a class should not be
marked as final if there is no interface they implement and that should be
fixed by extracting an interface.

If it's a value object, you don't need to mock it, wherever it exists.

Regards,
Alex

--000000000000faa13005f5359f5b--