[VOTE] Interface Default Methods

Chatter on the Interface Default Methods RFC has been quiet for
the past 6 days, and the feature freeze deadline is fast approaching
for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks
as usual.

Thanks to everyone who discussed weaknesses in the RFC during the
discussion phase.

I’m probably going to vote “yes” on this, but since the property accessors RFC won’t be ready for 8.3,1 and that RFC covers use of properties in interfaces, how useful will interface default methods be without interface properties?

Plenty useful, I think. Interfaces deal with abstractions, so there
are often things you can do without having state. Java's interfaces
don't allow properties, for instance, and they still have this
feature.

As an example, this poor-man Sequence interface works, because the
behavior and state for next is provided by the implementer:

<?php

interface Sequence {
    // return null to indicate the end of sequence
    function `next()`;

    function fold($initial, callable $f) {
        $reduction = $initial;
        while (($next = $this->next()) !== null) {
            $reduction = $f($reduction, $next);
        }
        return $reduction;
    }

    function reduce(callable $f) {
        $next = $this->next();
        return $next !== null
            ? $this->fold($next, $f)
            : null;
    }

    function into_array_list(): array {
        $array = [];
        while (($next = $this->next()) !== null) {
            $array[] = $next;
        }
        return $array;
    }
}

final class IteratorSequence
    implements Sequence
{
    function __construct(private Iterator $iter) {
        $this->iter->rewind();
    }

    function `next()` {
        $iter = $this->iter;
        if ($iter->valid()) {
            $next = $iter->current();
            $iter->next();
            return $next;
        }
        return null;
    }
}

function xrange($begin, $end) {
    $i = $begin;
    while ($i < $end) {
        yield $i++;
    }
}

$seq = new IteratorSequence(xrange(1, 10));
var_export($seq->into_array_list());
echo PHP_EOL;

Hi Andreas,

pon., 3 lip 2023 o 06:33 Andreas Heigl andreas@heigl.org napisał(a):

Am 03.07.23 um 02:11 schrieb Levi Morrison:

Chatter on the Interface Default Methods RFC has been quiet for
the past 6 days, and the feature freeze deadline is fast approaching
for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks
as usual.

Thanks to everyone who discussed weaknesses in the RFC during the
discussion phase.

I've voted "no" on this RFC for one simple reason:

For me an interface is about the abstraction of a contract. It defines
how different parts of code interact with one another without having to
know about the implementation.

With this RFC we are adding implementation details to the abstraction.

That requires knowledge about the implementation of different parts of
the code. Which we do not have when defining an interface.

I disagree, look at the example I presented in my other response,
one method can use another to provide a default method which you'd be
including via trait
in every implementing class because as it only uses another interface
method.
This means that you don't need to know anything about the implementation
itself at all.
You're free to use other interface methods and don't need any properties or
implementation details.

Cheers,
Michał Marcin Brzuchalski

Hi

Chatter on the [Interface Default Methods RFC][1] has been quiet for
the past 6 days, and the feature freeze deadline is fast approaching
for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks
as usual.

I'm not really sold on the proposal in the first place, but I find it
incredibly problematic that there were non-trivial changes to the RFC
text just 4 minutes before voting started and having the justification
"it will be easier to change if bad".

Combined with the phrasing of the email I'm replying to, it looks like
this proposal is attempted to be forced into PHP 8.3 for some reason,
without fully thinking it through / without allowing an in-depth
discussion. This is probably going to bite in the longer term.

Best regards
Tim Düsterhus

--

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

I suppose different people will think different things about what
'trivial' means, but the main changes were announced 6 days earlier on
the mailing list, and there was no discussion about it all. I consider
that to be fine. I also do not consider that to be hurried.

Le 03/07/2023 à 13:32, Michał Marcin Brzuchalski a écrit :

I voted "yes", my personal use case waits for this feature. My use
case example:

https://gist.github.com/brzuchal/89e9481bbd34a6ce3d95a68eabff038b

With interface default methods I'd no longer need traits that implement a
single or in rare cases 2 methods that
use their respective methods returning objects and iterate in Generator
fashion over a paginated result set.
This is not an issue if there is one implementation of the interface but
when I decorate to apply some:

• caching
• logging
• failover

then the trait has to be attached to every class besides that it has to
exist which is an additional symbol here.

Cheers,
Michał Marcin Brzuchalski

Please everyone yes to this !

I use Symfony daily, and the SomethingAwareInterface /
SomethingAwareTrait is very annoying, by having default method
implementations on interfaces, it would remove the use of having traits
at all. Everything would be much easier to read and write.

LoggerAwareInterface would no longer require us to use LoggerAwareTrait
on every class, etc...

This is kind of sugar candy I'd really love.

Best regards,

--

Pierre

Hey Michał

Hi Levi,

pon., 3 lip 2023 o 02:11 Levi Morrison morrison.levi@gmail.com napisał(a):

Chatter on the Interface Default Methods RFC has been quiet for
the past 6 days, and the feature freeze deadline is fast approaching
for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks
as usual.

Thanks to everyone who discussed weaknesses in the RFC during the
discussion phase.

I voted "yes", my personal use case waits for this feature. My use
case example:

https://gist.github.com/brzuchal/89e9481bbd34a6ce3d95a68eabff038b

I've added two already possible solutions to that as comments.

With interface default methods I'd no longer need traits that implement a
single or in rare cases 2 methods that
use their respective methods returning objects and iterate in Generator
fashion over a paginated result set.
This is not an issue if there is one implementation of the interface but
when I decorate to apply some:

• caching
• logging
• failover

That requires that you are in control over both the interface AND the
implementation. In which case you probably do not need an interface and
the Trait would be enough (using abstract public function in traits
works after all)

So you could even skip the implements part.

As the interface should be designed specifically to be
implementation-agnostic, adding implementation to the interface is
counter-productive.

Adding abstract methods to a trait and then just adding the traits is no
issue at all especially when you are in control of the interface AND the
implementation.

When you are NOT in control of the interface... well, you can't expect
to have a default implementation and I am already looking forward to the
complaints that it is great to have a default implementation, but not
that one.

There is a reason why the respective construct in Rust (which was
mentioned in the RFC) is called a Trait and not an Interface.

So to decouple the contract from the implementation it is necessary that
no implementation is part of the contract.

then the trait has to be attached to every class besides that it has to
exist which is an additional symbol here.

Stop using implements at all and solely rely on use.

My 0.02€

Cheers

Andreas

                                                           ,,,
                                                          (o o)

+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+

Chatter on the Interface Default Methods RFC has been quiet for
the past 6 days, and the feature freeze deadline is fast approaching
for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks
as usual.

Thanks to everyone who discussed weaknesses in the RFC during the
discussion phase.

The voting period is about half-way through. For your information,
it's currently sitting at 10 yes and 13 no votes. Thanks to everyone
who has voted so far.

I really liked this idea actually but I'm still not so sure about it,
what would be the "right" approach. Just one question though. With
this, also the protected methods would be possible to define in the
interface? And what about the properties? Properties would be part of
some other RFC?

Perhaps a little too late, but I was wondering whether folks that voted NO
would reconsider in case this was made a bit more opt-in.

There could be some bikesheding around syntax but essentially the idea
would be a new RFC targeting 8.4 with the following adjustment:

interface Foo {
public function bar() {
echo "hello";
}
}

class Out implements Foo {}

// RFC is ignored.
// Fatal error: Class Out contains 1 abstract method and must therefore be
declared abstract or implement the remaining methods (Foo::bar)

class In use Foo {}

// RFC takes effect.

class In extends Foo {}

// RFC takes effect but the class is no longer allowed to extend abstract
classes, only interfaces

class In with Foo {}

// RFC takes effect

class In as Foo {}

// RFC takes effect

==========

In the spirit of minimizing impact, the proposed syntaxes only use keywords
already present in the language as to not run the risk of causing more
issues (https://www.php.net/manual/en/reserved.keywords.php).

This idea occurred to me when someone pointed out that they don't want to
implement interfaces which might bring code into their class.
Does this adjustment makes things better, worse or the same?

Looks - sadly to me - like this isn't going to pass. I don't have vote
karma and if I did it wouldn't make a difference to the outcome, but it
would be really good for those of us who can't vote on the feature to hear
from some of the people who voted against it why they chose no. The
feedback from the discussion here seemed overall positive. It's one of
those things that's just a bit opaque to me, that quite often I see people
voting no on an RFC and we haven't heard from them in the relevant
internals threads, so we just never know why something was rejected or what
the author could have said or changed in the RFC to persuade them.

I share some of the sentiment. Although I think we have quite a few people
without a vote here on this thread which might had been enough to approve
this feature if we all collectively had a vote.

Unfortunately the voting system is another broken problem without a fix and
it's a really sad outcome at the end.

This would had been one of the best PHP improvements since Construction
Property Promotion and Short Arrow Functions

Maybe the resistance to the proposal would be far less if the RFC, and
implementation, would check at compile time that the default
implementations only rely on known existing functions available to the
interface.

I asked in the discussion if this was a possibility, and it's the biggest
concern I had about the feature as proposed. Rowan answered "As the RFC
says, it introduces a form of multiple inheritance, and inheritance in PHP
doesn't make any such guarantee" and Levi added "I hope static analysis can
fill the gap here, but don't think these checks are necessary to ship this
feature" - and this is fair enough, I think; we kind of do accept the
nature of PHP is that there is some anti-intuitive weirdness versus
statically compiled languages. I wasn't convinced at first but I've come to
be persuaded even if it's not a perfect implementation of default methods
as I would have wanted them, it's still a significant improvement on the
trait + interface model we have now. It's ultimately a step in the right
direction and I'm disappointed now it looks like it's not going to happen,
at least in the next release. Would be good to know from some of the no
votes if they'd reconsider for a future version.

Chatter on the Interface Default Methods RFC has been quiet for
the past 6 days, and the feature freeze deadline is fast approaching
for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks
as usual.

Thanks to everyone who discussed weaknesses in the RFC during the
discussion phase.

Although I like the idea, I think the main reason for the pushback is how
close this is being voted on before feature freeze when the RFC +
implementation was updated very recently before.
And personally I think, considering this, I would also delay implementing
this.
We have at least 2 other major RFCs that are being pushed back (Property
Hooks and Function autoloading) due to time constraints.

Maybe it's time for a more meta discussion about the absurdly long release
process PHP has of releasing many intermediate versions that seem to get no
testing from userland.

For everyone against this feature, I would urge you to understand the
distinction between "type classes" and Java-like "interfaces" (which is
effectively what PHP interfaces are).
A good article is the following one:
https://diogocastro.com/blog/2018/06/17/typeclasses-in-perspective/

I also find it baffling the lack of understanding around this feature.
Generic programming exists, and it operates on a level where a method can
have a "concrete" default representation and still represent the genericity
to its fullest.
Examples have already been given, such as the Comparable, Equatable, or
Iterator type classes.
Considering, Haskell, Rust, Scala, and modern PL theory sees no issue with
that, I struggle to understand the resistance here.

If I could play armchair shrink for a moment, I suspect a lot of people come from a background where "interface is just the behavior definition, not implementation" was drilled into them. Which... is the case in older Java when most of us went through school using older Java. So it's natural to think that is just a rule of how languages work, and so default methods in interfaces is just some weird nonsense from people who don't understand language theory because you didn't learn it in school.

At least, I know that description applies to me, so I'm assuming it applies to at least some other folks around here. :-)

Realizing "oh, wait, I was wrong about the theory of how things work" is uncomfortable, and hard for a lot of people. I was initially luke-warm on it for that reason. But seeing how many languages have adopted some form of default methods and lived to tell the tale is convincing for me that it actually is a viable "build up a class from separate pieces without having to manually write 50 proxy methods" solution. There may be smaller issues with it that need to be ironed out (enforcing methods being defined, it working better with interface properties, etc.), but the core idea seems to be sound.

It's taken me a while to get used to going through that "oh wait, I was wrong" process, so at this point it's not an ego-hit. But that's not a process everyone has gone through.

In short, I suspect at least much of the pushback is "that is weird and not normal, according to the normal I first learned, so it must be a bad idea," and people just stop there.

(If you voted no and the above description doesn't apply to you, please do explain what your alternate reasoning is, because RFC authors desperately need more feedback than we get right now.)

--Larry Garfield

Hi

I find the Rust Seek trait(/type class) a very concise example of the
usefulness, and where the implementation of a default method is far from
concrete.
Requiring an implementation to provide the implementation for seek(int
$position)
But being able to provide the trivial implementation of rewind() which is
seek(0);

(I'm not a Rust expert, but I've shipped production software with it. So
the following might not be entirely accurate, in this case I'm happy to
be corrected)

I don't think it is useful to compare PHP or this proposed RFC to what
Rust does. My understanding is that Rust methods are effectively just
syntax sugar for a regular function call. Specifically they have an
explicit parameter for the $this value (commonly called self).

Furthermore "methods" in Rust are effectively namespaced using the
struct or trait name they are defined in, thus implementing multiple
traits with a large number of default-implemented methods with generic
names will not cause conflicts:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=5fe33b54187f110a8794c90e3a608466

In PHP all the methods would reside in a flat namespace. From my
experience this can already be a problem when needing to implement more
than one interface at the same time and this is not likely to improve if
the number of methods in an interface would increase (e.g. the mentioned
Iterator trait).

The use-case of reducing the BC impact of extending an interface by
providing a default method would also risk accidental collisions with
methods that already happen to exist in a child class. Incidentally this
effectively matches one of the examples given in my #[\Override] RFC
(the 4th Laravel Eloquent example) -
https://wiki.php.net/rfc/marking_overriden_methods#examples - though to
be clear #[\Override] cannot (yet) protect against that, because "no
implicit override" was left as future scope.

See also: https://phpc.social/@heiglandreas/110649571908678102. This
effectively makes the main selling point of the RFC moot. I'm aware this
limitation is acknowledged in the "Backward Incompatible Changes"
section. I do not think this makes it less of a problem, though.

Best regards
Tim Düsterhus