Hello,
I’ve opened the vote on the Optional interfaces RFC.
https://wiki.php.net/rfc/optional-interfaces
Implementation: https://github.com/php/php-src/pull/17288
Discussion: https://externals.io/message/126185
The voting will be closed on 2025-03-29 00:00:00 UTC.
BR,
Juris
Hi,
I voted yes as we have got a specific use case in core - user stream wrapper. More details can be found in https://github.com/php/php-src/issues/10506 .
Regards
Jakub
On Fri, Mar 14, 2025 at 10:52 AM Jakub Zelenka <bukka@php.net> wrote:
Hi,
I voted yes as we have got a specific use case in core - user stream wrapper. More details can be found in https://github.com/php/php-src/issues/10506 .
Ah I should have probably read it first. 
I confused it with optional methods in interface so this doesn’t really help with the above. Still seems quite useful so keeping my vote.
Regards
Jakub
On 2025-03-14 10:09, Juris Evertovskis wrote:
Hello,
I’ve opened the vote on the Optional interfaces RFC.
https://wiki.php.net/rfc/optional-interfaces
Implementation: https://github.com/php/php-src/pull/17288
Discussion: https://externals.io/message/126185
The voting will be closed on 2025-03-29 00:00:00 UTC.
BR,
Juris
Hello again,
A reddit discussion has started as well: https://www.reddit.com/r/PHP/comments/1jbcbtx/php_rfc_optional_interfaces/
It might be useful to those who haven’t made their minds up yet. It contains a lot of opinions with both criticism and usecases of this feature.
The key point, hoewever, seems to be that the naming of the feature is excremental and very easy to misunderstand. I suppose the naming issue can be solved separately (if a better name is found) and the documentation can use a different naming and description if the RFC itself passes.
BR,
Juris
On Sat, Mar 15, 2025, 11:25 Juris Evertovskis <juris@glaive.pro> wrote:
The key point, hoewever, seems to be that the naming of the feature is excremental and very easy to misunderstand. I suppose the naming issue can be solved separately (if a better name is found) and the documentation can use a different naming and description if the RFC itself passes.
Hi Juris,
Looking a bit into the naming issue, it feels like shifting from “optional interface” to “optionally implements interfaces” is something that could have help.
The RFC could have used throughout the text the adverb “optionally” to the verb “to implement” or adjective “optional” to “implementation” instead of as an adjective to “interface”.
Also the name would have been “optional interface implementation”.
If you agree, and if the RFC passes, this could at least be documented as such.
Was not able to find other words that matches better, as all have some drawbacks.
–
Alex
On Saturday, 15 March 2025 at 09:23, Juris Evertovskis <juris@glaive.pro> wrote:
On 2025-03-14 10:09, Juris Evertovskis wrote:
Hello,
I’ve opened the vote on the Optional interfaces RFC.
Implementation: [RFC] Optional interfaces by tontonsb · Pull Request #17288 · php/php-src · GitHub
Discussion: [RFC] [Discussion] Optional interfaces - Externals
The voting will be closed on 2025-03-29 00:00:00 UTC.
BR,
Juris
Hello again,
A reddit discussion has started as well: https://www.reddit.com/r/PHP/comments/1jbcbtx/php_rfc_optional_interfaces/
It might be useful to those who haven't made their minds up yet. It contains a lot of opinions with both criticism and usecases of this feature.
The key point, hoewever, seems to be that the naming of the feature is excremental and very easy to misunderstand. I suppose the naming issue can be solved separately (if a better name is found) and the documentation can use a different naming and description if the RFC itself passes.
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\)
On Thu, Mar 20, 2025, at 11:09 AM, Gina P. Banyard wrote:
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
On 2025-03-20 18:09, Gina P. Banyard wrote:
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
On 3/14/25 03:09, Juris Evertovskis wrote:
Hello,
I've opened the vote on the Optional interfaces RFC.
Implementation: [RFC] Optional interfaces by tontonsb · Pull Request #17288 · php/php-src · GitHub
Discussion: [RFC] [Discussion] Optional interfaces - Externals
The voting will be closed on 2025-03-29 00:00:00 UTC.
BR,
Juris
I voted "yes" on this.
I've heard from a number of folks over the years who have wanted this feature, and the use cases in examples 4 and 5 sold me on it.
I would strongly recommend coming up with a better name for this feature in the documentation, and I also think the documentation will need strong examples and also describe potential use-cases (like the RFC does).
Cheers,
Ben
On Fri, Mar 14, 2025 at 4:12 AM Juris Evertovskis <juris@glaive.pro> wrote:
Hello,
I’ve opened the vote on the Optional interfaces RFC.
Implementation: [RFC] Optional interfaces by tontonsb · Pull Request #17288 · php/php-src · GitHub
Discussion: [RFC] [Discussion] Optional interfaces - Externals
The voting will be closed on 2025-03-29 00:00:00 UTC.
BR,
Juris
I have voted no. I think this could be a good thing, but I was simply
not confident enough in it to vote yes at this time. Maybe in the
future.
Hello,
The voting has concluded with 15 votes in favor and 19 against. As such, the RFC has been declined.
https://wiki.php.net/rfc/optional-interfaces
Thank you all for taking the time to consider the proposal and casting your votes. I’m especially grateful to those who helped refine the RFC by providing feedback on this list, as well as to those who helped with the implementation on GitHub.
BR,
Juris