Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120792
MIME-Version: 1.0
References: <CAFMT4Nq3y+XKUP7aG7F7aht1DdM7dpqxMT-hcS+Nyvc9FaT=+A@mail.gmail.com>
In-Reply-To: <CAFMT4Nq3y+XKUP7aG7F7aht1DdM7dpqxMT-hcS+Nyvc9FaT=+A@mail.gmail.com>
Date: Wed, 12 Jul 2023 05:00:51 +0100
Message-ID: <CAFPFaMJyE9EWv=8RdC=T0sB1bt6f5CrQikh3s+p6oTo-RbM6BQ@mail.gmail.com>
To: Levi Morrison <morrison.levi@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ad41730600424346"
Subject: Re: [PHP-DEV] [VOTE] Interface Default Methods
From: george.banyard@gmail.com ("G. P. B.")

--000000000000ad41730600424346
Content-Type: text/plain; charset="UTF-8"

On Mon, 3 Jul 2023 at 01:11, Levi Morrison <morrison.levi@gmail.com> wrote:

> 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.
>
> Thanks to everyone who discussed weaknesses in the RFC during the
> discussion phase.
>
>   [1]: https://wiki.php.net/rfc/interface-default-methods
>

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.

Moreover, saying this capability should not be added to PHP because we have
inferior tools X + Y + Z to achieve what this does is counterproductive
and, IMHO, shows a clear lack of understanding of the issues PHP's model
currently has.
Traits are, and have always been, terribly designed. Assisted copy-paste
that has no relation to the type the implementation it provides fulfils.
Abstract classes allowing default implementations, but enforcing hierarchy
thus type relations, meaning they are unsuitable for when one wants
genericity (for separating concerns).
Interfaces which allow the creation of new types, but no generic
implementation which depend on a function specified by said interface.

Objectively, the current situation is suboptimal.
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.
Or that at least one of the methods would remain "abstract".
However, that does not seem what the discourse is.

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);

Sincerely,

George P. Banyard

--000000000000ad41730600424346--