Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120809
Message-ID: <48d25edf-ce28-b912-c983-31ae5c64b6f4@bastelstu.be>
Date: Thu, 13 Jul 2023 20:02:28 +0200
MIME-Version: 1.0
To: "G. P. B." <george.banyard@gmail.com>
Cc: internals <internals@lists.php.net>
References: <CAFMT4Nq3y+XKUP7aG7F7aht1DdM7dpqxMT-hcS+Nyvc9FaT=+A@mail.gmail.com>
 <CAFPFaMJyE9EWv=8RdC=T0sB1bt6f5CrQikh3s+p6oTo-RbM6BQ@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAFPFaMJyE9EWv=8RdC=T0sB1bt6f5CrQikh3s+p6oTo-RbM6BQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [VOTE] Interface Default Methods
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 7/12/23 06:00, G. P. B. wrote:
> 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