Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119590
MIME-Version: 1.0
References: <CABAhh3Ed1uwS8bY75Rz_4FkhU4Bq7Fx0TexnLgQQcvhygcTgvQ@mail.gmail.com>
 <CAAwdEzDH_NoRcNwWh1MULqNAHu6g0S0oi8j2XtgZOKWYA+fPwQ@mail.gmail.com> <CABAhh3HpcuHPBKwd+8_-_GFy2gVy4-s9_+6ytU2ijZQKF4RD=w@mail.gmail.com>
In-Reply-To: <CABAhh3HpcuHPBKwd+8_-_GFy2gVy4-s9_+6ytU2ijZQKF4RD=w@mail.gmail.com>
Date: Tue, 21 Feb 2023 18:15:09 +0200
Message-ID: <CAAwdEzBYFPtf8WBvkYm8gsOeANFC-pMN6NHQqLRUsTF7SgzLKw@mail.gmail.com>
To: someniatko <someniatko@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006426ec05f53816b2"
Subject: Re: [PHP-DEV] Class Re-implementation Mechanism
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--0000000000006426ec05f53816b2
Content-Type: text/plain; charset="UTF-8"

On Tue, Feb 21, 2023 at 3:30 PM someniatko <someniatko@gmail.com> wrote:

> > 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.
>
> > 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.
>
>
Understood, thanks for explaining.
So it's mostly a syntactic sugar that allows defining an interface for the
current class that is already implemented by the current class.

The interface name is the same as the class name and based on the context,
you either use one or the other.
There are some places where this could get in conflict like (new
ReflectionClass(A::class))->isInterface(). But also internally things might
be difficult to sort out to know what to use one or the other.

To have a perfect syntax-sugar, why not also allow the interface name to be
specified?
Something like:
final class interface(ServiceInterface) Service {
    public function method1() {}
    protected function method2() {}
}

that would generate:
interface ServiceInterface {
    public function method1();
}
final class Service implements ServiceInterface {
    public function method1() {}
    protected function method2() {}
}

As explained previously (and now I got that), autoloading will not work in
this case. But some classmaps can be configured for composer or you could
just force class loading with class_exists() in limited places where this
is needed (in tests).

Alex

--0000000000006426ec05f53816b2--