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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
