On Tuesday, 11 March 2025 at 16:37, Juris Evertovskis <ju...@glaive.pro> wrote:
> Hey, > > Just a headsup that I plan to start the vote in a couple of days. Please let > me know if there are concerns that might affect your stance on this proposal. > > https://wiki.php.net/rfc/optional-interfaces I will be voting against this. I understand why you might want this, but this seems to be a very niche requirement and messing with type level guarantees is not something I want to see. The RFCs implies that any invalid code will be caught at compile time, but this is not true. If the optional dependency is never present, you can violate the interface in whatever way you want, which you might not be doing on purpose. Moreover, this also does not help if an optional dependency changes the requirements of their interface and is present, so you would still need to do those "hacky" workarounds. (e.g. if a dependency changes how they define the interface in a major release) The fact an interface can become "available" at a later stage and classes defined prior to it being available having an optional dependency on it not implementing it is bound to be weird and unintuitive. And ultimately, this does not really solve the problem of supporting optional dependencies, or using your object in ways that are compatible with another dependency. Because it still relies on a library/framework/whatever maintainer to add, possibly infinite, optional interfaces for any new optional dependency which might want to interact with instances of your classes. As such I would prefer something which is more similar to type classes ("add type information outside of your class declaration"). Or even explicit runtime interface implementation which could for example look like: $obj implements OptionalDependency; someFunctionFromOptionalDependency($obj); which gives control to the *user* where and how class instance may interact with dependencies that are outside of your control, and that you don't even need to care of. Best regards, Gina P. Banyard >
