Hi Juris On Sun, Feb 9, 2025 at 10:16 PM Juris Evertovskis <ju...@glaive.pro> wrote: > > https://wiki.php.net/rfc/optional-interfaces
Thanks for your efforts. I've reviewed the patch, it seems there are still a few issues and it would be great if we could solve them before this goes into voting. A few thoughts on the RFC itself: You mention `#[Override]` in the RFC and how it will work on optional interfaces that are available at runtime (the `TestClass::method()` example). Given the interface is implemented as optional, it is to be expected that the interface will go away under certain configurations. This will break, because the method is no longer overridden. Hence, it might be best to also disallow `#[Override]` on optional interface methods, to signal the breaking for the missing interface scenario. > A class only conforms to types that are actually implemented. Just as a note, this also has some semantic implications. Notably `$object instanceof OptionalInterface` will evaluate to `false` without errors when the interface goes missing. To catch this issue with static analysis, the project will need to be analysed without the interface being available, or they will need to gain new rules that catch such expressions that can lead to inconsistent results. Also, when I read the subject "optional interfaces", what came to mind was "an interface that may or may not be implemented", i.e. similar to Objective-C's optional protocol methods [1]. I'm not sure if the naming can be improved. Overall, I'm not particularly convinced this is a big problem that needs solving, but I'll leave that up to framework designers to decide. Ilija [1] https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/WorkingwithProtocols/WorkingwithProtocols.html#//apple_ref/doc/uid/TP40011210-CH11-SW6
