Re: [RFC] Interface Default Methods
| From: | Rowan Tommins | Date: | Tue, 20 Jun 2023 13:29:48 +0000 |
| Subject: | Re: [RFC] Interface Default Methods | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-120646@lists.php.net to get a copy of this message | ||
On Tue, 20 Jun 2023 at 13:29, David Gebler <davidgebler@gmail.com> wrote:
> Yeah I suppose I'm just saying "Interface default methods" can be
> interpreted a few different ways and there's key differences between
> Java-style, versus syntax sugar for mixing an interface and a trait in to
> one unit, versus a user can effectively extend multiple abstract classes
> but with interface keyword.
>
As far as I can see, "Java-style", and " effectively extend multiple
abstract classes" are actually the same thing, and per my e-mail that's
what I think the RFC is proposing. The "mixing an interface and a trait"
interpretation would not lead to the method resolution shown.
Additional constraints in Java around calling *public* methods outside the
interface are just a consequence of how it performs static analysis and
compilation on *all* classes, not something specific to interface default
methods. The lack of those constraints in PHP is likewise not something
that's specific to this proposal, the language *always* allows you to
attempt any method call on any object, including $this, even if a type
checker would say the call is invalid.
Regards,
--
Rowan Tommins
[IMSoP]