[RFC] Interface Default Methods

Hello, PHP Internals,

I am moving my RFC for interface default methods to discussion:
https://wiki.php.net/rfc/interface-default-methods.

This can be a useful tool for a few reasons:

1. It can make implementing an interface easier when certain methods
   can be implemented by other methods in the interface. For example, if
   Countable had an isEmpty(): bool method, it could be implemented
   by doing $this->count() > 0. Of course, if an implementation can be
   more efficient, they are still free to implement it how they want.
2. It can mitigate BC breaks in some cases. It's somewhat common for
   authors to want to expand new methods onto existing interfaces over
   time. Although this would still be a BC break, it moves it from a
   massive change (every single implementor must add something, even if
   it's a stub, or it will fail to compile) to a naming collision issue
   only (only classes which already had a method of the same name will
   fail to compile).

There is prior art for this feature in both Java and C#. There may be
other languages, but I was aware of at least these.

Note that the RFC links to a partial implementation. If there are two
or more interfaces with default methods of the same shape (name, args,
etc) and a class implements both interfaces and doesn't provide a
concrete implementation, which default implementation should be
chosen? There is a proposal for resolving this in some cases which is
modelled after Java's implementation, but it isn't implemented.

Thank you for your time. I look forward to productive feedback.

Levi Morrison

Hi Levi,

Thanks for the RFC. The usecase seems clear.

There are two things I'm missing on an initial read of the RFC.

Adding a default implementation to an existing interface method will
not break existing code, because every existing usage has a higher
priority than the default.

A: How would this work if the existing method in the implementing class
has a different function signature than the newly introduced method in
the interface ?
There are two aspects to this:

1. What if the existing method has different parameters ?
2. What if the existing method has the same parameters, but
   different/incompatible parameter/return types ?

B: How does the ability to add default method implementations to an
interface compare to providing an abstract class implementing the
interface and providing the default method implementations ?

Smile,
Juliette

I loved the proposal and I think this has the potential to be a huge
developer experience improvement, perhaps at least as great as property
constructor promotion and match().

Just a side note though, in the Backward Compatibility section, I would
think that only "None" should be declared. From the PHP binary perspective,
running code before and after this change has absolutely 0 impact/breaking
changes.
The feature may introduce a new way for Users of PHP to break BC with
Other Users of PHP. The language change itself has no impact on PHP code
written prior to the feature. The additional note about how users may break
BC by using the feature would be a description of the feature itself, thus
might be best declared as part of the Proposal instead.

I wish us all the best of luck with this proposal.

On Thu, Jun 15, 2023 at 12:48 AM Levi Morrison via internals <
internals@lists.php.net> wrote:

Hello, PHP Internals,

I am moving my RFC for interface default methods to discussion:
https://wiki.php.net/rfc/interface-default-methods.

This can be a useful tool for a few reasons:

1. It can make implementing an interface easier when certain methods
   can be implemented by other methods in the interface. For example, if
   Countable had an isEmpty(): bool method, it could be implemented
   by doing $this->count() > 0. Of course, if an implementation can be
   more efficient, they are still free to implement it how they want.
2. It can mitigate BC breaks in some cases. It's somewhat common for
   authors to want to expand new methods onto existing interfaces over
   time. Although this would still be a BC break, it moves it from a
   massive change (every single implementor must add something, even if
   it's a stub, or it will fail to compile) to a naming collision issue
   only (only classes which already had a method of the same name will
   fail to compile).

There is prior art for this feature in both Java and C#. There may be
other languages, but I was aware of at least these.

Note that the RFC links to a partial implementation. If there are two
or more interfaces with default methods of the same shape (name, args,
etc) and a class implements both interfaces and doesn't provide a
concrete implementation, which default implementation should be
chosen? There is a proposal for resolving this in some cases which is
modelled after Java's implementation, but it isn't implemented.

Thank you for your time. I look forward to productive feedback.

Levi Morrison

--

To unsubscribe, visit: https://www.php.net/unsub.php

--
Marco Deleu

Hi Levi

I am moving my RFC for interface default methods to discussion:
https://wiki.php.net/rfc/interface-default-methods.

This or a similar concept makes sense to me. The proposal seems
similar to Swift protocol extensions, or Rust traits, with the
exception that function default implementations may only be defined in
the interface itself.

Note that there's a large overlap between this proposal and extending
traits to allow implementing interfaces.
https://wiki.php.net/rfc/traits-with-interfaces The main difference is
how you would use the feature from a given class, i.e. using an
interface implementation or a trait usage. Implementing interfaces
from traits would require declaring both a trait and an interface. I
do think your proposal is the more natural approach.

The redundancy of interfaces and traits after this RFC are also
somewhat unfortunate. Both interfaces and traits could inject default
behavior into classes. Both could enforce implementation of methods in
classes (traits through abstract methods). My intuition is that
interface default implementations should be used for public APIs
(because this provides an abstracted interface), while traits should
be used for protected/private ones (because non-public methods can't
be added to interfaces). The other obvious difference is that
interfaces don't allow manual conflict resolution while traits do.

The RFC doesn't mention default implementations for static methods.
I'm not sure there's a use case but it might make sense to explicitly
mention whether they are supported.

Ilija

Hello, PHP Internals,

I am moving my RFC for interface default methods to discussion:
https://wiki.php.net/rfc/interface-default-methods.

This can be a useful tool for a few reasons:

1. It can make implementing an interface easier when certain methods
   can be implemented by other methods in the interface. For example, if
   Countable had an isEmpty(): bool method, it could be implemented
   by doing $this->count() > 0. Of course, if an implementation can be
   more efficient, they are still free to implement it how they want.
2. It can mitigate BC breaks in some cases. It's somewhat common for
   authors to want to expand new methods onto existing interfaces over
   time. Although this would still be a BC break, it moves it from a
   massive change (every single implementor must add something, even if
   it's a stub, or it will fail to compile) to a naming collision issue
   only (only classes which already had a method of the same name will
   fail to compile).

There is prior art for this feature in both Java and C#. There may be
other languages, but I was aware of at least these.

Note that the RFC links to a partial implementation. If there are two
or more interfaces with default methods of the same shape (name, args,
etc) and a class implements both interfaces and doesn't provide a
concrete implementation, which default implementation should be
chosen? There is a proposal for resolving this in some cases which is
modelled after Java's implementation, but it isn't implemented.

Thank you for your time. I look forward to productive feedback.

This would essentially replace the semi-common pattern of providing an interface, and a trait that implements most of the interface for you.

I have many conflicting thoughts on this RFC.

On the plus side, the flexibility it provides sounds delightful, and it would effectively render abstract classes almost entirely pointless.

On the down side, multiple inheritance is often avoided for a reason, and as Ilija noted it doesn't completely replace traits and base classes as it doesn't apply to non-public methods.

From a BC perspective it seems fine. It's at worst the same as now, and potentially makes extending existing interfaces easier.

I think I am overall positive, but still a bit uneasy and having a hard time articulating why.

--Larry Garfield

On Thu, Jun 15, 2023 at 12:48 AM Levi Morrison via internals <
internals@lists.php.net> wrote:

Hello, PHP Internals,

I am moving my RFC for interface default methods to discussion:
https://wiki.php.net/rfc/interface-default-methods.

This can be a useful tool for a few reasons:

1. It can make implementing an interface easier when certain methods
   can be implemented by other methods in the interface. For example, if
   Countable had an isEmpty(): bool method, it could be implemented
   by doing $this->count() > 0. Of course, if an implementation can be
   more efficient, they are still free to implement it how they want.
2. It can mitigate BC breaks in some cases. It's somewhat common for
   authors to want to expand new methods onto existing interfaces over
   time. Although this would still be a BC break, it moves it from a
   massive change (every single implementor must add something, even if
   it's a stub, or it will fail to compile) to a naming collision issue
   only (only classes which already had a method of the same name will
   fail to compile).

There is prior art for this feature in both Java and C#. There may be
other languages, but I was aware of at least these.

Note that the RFC links to a partial implementation. If there are two
or more interfaces with default methods of the same shape (name, args,
etc) and a class implements both interfaces and doesn't provide a
concrete implementation, which default implementation should be
chosen? There is a proposal for resolving this in some cases which is
modelled after Java's implementation, but it isn't implemented.

Thank you for your time. I look forward to productive feedback.

Levi Morrison

--

To unsubscribe, visit: https://www.php.net/unsub.php

A question just occurred to me. Building up on the example of the RFC, is
the following snippet valid and would it behave as expected?

interface Interface1 {
    function method1() { echo __METHOD__ . "\n"; }
}

interface Interface2 {
    function method1() { echo __METHOD__ . "\n"; }
}

class Class1 implements Interface1, Interface2 {
    function method1() {
        $result = Interface1::method1();

        Interface2::method1();

        return $result;
    }
}

$result = (new Class1())->method1();

--
Marco Deleu

On Thu, Jun 15, 2023, 06:48 Levi Morrison via internals <
internals@lists.php.net> wrote:

Hello, PHP Internals,

I am moving my RFC for interface default methods to discussion:
https://wiki.php.net/rfc/interface-default-methods.

Thank you for your time. I look forward to productive feedback.

Hi Levi,

Thank you for this!
I like the proposal and I think it fits well.
I'm used to it from Java and I don't know any reason for it to be
considered a bad practice since it was introduce, about 9-10 years ago.

1. Do we want to allow also private methods in the interface so that it
   allows code reuse or better code organization in smaller methods? Java
   introduced this only in the next version.
   The private methods would be invisible to implementing classes and to
   anything else, of course.
   We can also add them at a later point but it might be better to have the
   feature complete now.

Sidenote: I don't think protected method should ever exist on interfaces;
that should remain for abstract classes use case.

2. The only use case for myself for ever using traits would be if traits
   would offer a default implementation for an interface. Now with a default
   implementation offered by interface itself, sounds even better.
   However, I can see how there could be more than one provided default
   implementation that can be offered.
   Would a method implemented by a trait have higher precedence over the
   interface default implementation?
   Would a trait offered implementation be directly usable by the interface?

Thanks,
Alex

On Thu, Jun 15, 2023 at 4:48 AM Levi Morrison via internals <
internals@lists.php.net> wrote:

I am moving my RFC for interface default methods to discussion:
https://wiki.php.net/rfc/interface-default-methods.

Can I ask, the RFC doesn't say - does your implementation ensure default
implementations can only call other methods which exist on the interface in
the same manner as Java? i.e. the following would give some sort of error?

interface A {
public function foo(): void {
$this->bar();
}
}

class B implements A {
public function bar(): void {
...
}
}

But the following would be okay?

interface A {
public function foo(): void {
$this->bar();
}

public function bar(): void;

}