[VOTE] Optional Interfaces View as Markdown

Frankly, the comment from u\phuncky [1] mentioning the possibility of
bad interactions with default interface methods (something I think is
more important than this) is reinforcing my opinion that this RFC solve
the problem in a bad way.
And another user [2] was basically suggesting my previous solution of
adding support for type classes/runtime implementation of interfaces.

Best regards,

Gina P. Banyard

[1] https://www.reddit.com/r/PHP/comments/1jbcbtx/comment/mhtpwa2/
https://www.reddit.com/r/PHP/comments/1jbcbtx/comment/mhtpwa2/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
[2] https://www.reddit.com/r/PHP/comments/1jbcbtx/comment/mhvxo5j/
https://www.reddit.com/r/PHP/comments/1jbcbtx/comment/mhvxo5j/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

I quite like the Rust-ish style, but given PHP's small compilation units and autoloading needs, I don't know how it could be done. (Someone wiser than I may know of a way, but I cannot think of one.)

--Larry Garfield

Hi

Am 2025-03-20 17:09, schrieb Gina P. Banyard:

And another user [2] was basically suggesting my previous solution of
adding support for type classes/runtime implementation of interfaces.
[…]
[2] https://www.reddit.com/r/PHP/comments/1jbcbtx/comment/mhvxo5j/

I don't see how this could (usefully) work in PHP, which doesn't scope
the methods on a “per interface” basis / which makes methods just some
syntactic sugar for a function that takes the object as a parameter.
Once you have more than a handful of interfaces on a single object you
are bound to have naming / signature conflicts, unless the interfaces
use some oddly-specific name for their methods. Two different
serialization libraries might want to use serialize() for their
methods, but using incompatible signatures (e.g. to pass additional
options).

It works well for Rust, since each trait will need to be imported
explicitly for the associated methods to be available. And then you can
also call the method as a free-standing function, just passing the
appropriate struct as a parameter to disambiguate them.

Best regards
Tim Düsterhus

And another user [2] was basically suggesting my previous solution of
adding support for type classes/runtime implementation of interfaces.

Hey,

There are two ideas -- the $object implements Iface that you suggested
and the SomeClass implements Iface that was suggested on reddit. I see
the instance-specific one as something that a consumer can do in their
project if they know that the $object actually fits where needed. That
would be a cool feature per se. But it seems to me it would take a lot
of bridging code to provide such "dynamically implementing" objects if
you're the package author.

I'll address the SomeClass implements Iface expression vs class SomeClass implements ?Iface hereinafter.

The ?OptionalInterface would always be within the class definition and
in a real-life project with PSR-4 you could check the interface
existence by inspecting the file tree or click-throughing the name in an
IDE.

It's not obvious to me how the runtime implementation expressions could
be in such a discoverable spot. The expression could be anywhere in the
project. And it will likely be inside conditionals. It would surely be
hard to discover manually. I'm not a developer of stan tooling, but I
expect it would complicate automated static analysis as well.

BR,
Juris