Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119588
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.2\))
In-Reply-To: <CABAhh3Ed1uwS8bY75Rz_4FkhU4Bq7Fx0TexnLgQQcvhygcTgvQ@mail.gmail.com>
Date: Tue, 21 Feb 2023 20:25:32 +0700
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <EDF50A43-39C1-4725-B3AE-D3599A41EEF8@koalephant.com>
References: <CABAhh3Ed1uwS8bY75Rz_4FkhU4Bq7Fx0TexnLgQQcvhygcTgvQ@mail.gmail.com>
To: someniatko <someniatko@gmail.com>
Subject: Re: [PHP-DEV] Class Re-implementation Mechanism
From: php-lists@koalephant.com (Stephen Reay)



> On 21 Feb 2023, at 18:52, someniatko <someniatko@gmail.com> wrote:
>=20
> Hi again, internals
>=20
> My marathon of some crazy ideas continues :D, with less crazy one this =
time.
>=20
>=20
> ## Idea
>=20
> Allow "reimplementing" the non-static public API (that is public
> properties and methods, excluding constructor) of a class by other
> classes like this:
>=20
> ```php
> final class interface A {
>    public string $s;
>=20
>    public function __construct(string $s) { $this->s =3D $s; }
>=20
>    public static function fromInt(int $i): self { return new
> self((string) $i); }
>=20
>    public function foo(): int { return 42; }
> }
>=20
> final class B implements A {
>    public string $s =3D 'hello';
>=20
>    public function foo(): int { return 69; }
> }
>=20
> function usesA(A $param): void {}
>=20
> usesA(new B); // this works
> ```
>=20
>=20
> ## Explanation
>=20
> Consider there is a class like this:
>=20
> ```php
> final class Service {
>    public function __construct(private SomeDependency $dependency) {}
>    // ...
> }
>=20
> final class SomeDependency {
>    // ...
> }
> ```
>=20
> 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.
>=20
> 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
>=20
> 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:
>=20
> ```php
> final class interface C {}
> final class D implements C {}
> ```
>=20
> 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.
>=20
> Soo..., what do you think? Could this be a valuable addition to the =
language?
>=20
> Regards,
> Illia / someniatko
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>=20

Hi

It=E2=80=99s possible I=E2=80=99m missing something here, because it=E2=80=
=99s hard to tell which parts are new syntax you=E2=80=99re suggesting, =
and which parts are unfortunate typos=E2=80=A6

Can you explain how using a regular interface (or even an abstract base =
class if you prefer) doesn=E2=80=99t already achieve what you want?



Cheers

Stephen=20