Hey Gina,
On 12.3.2025 06:16:15, Gina P. Banyard wrote:
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.
I'd assume you'd require-dev all your dependencies and see the issues at
compile time.
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)
That's what version requirements are for in composer. Similarly, if a
major release is released, you just implement the methods defined on the
interface for all major versions you support. This does not need the
hacky workarounds in any way.
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.
This is not more or less intuitive than the current workarounds you'll
have to do with "if (class_exists('interfacename'))".
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.
It does not and it does not need to. That's a wholly different feature
(e.g. "when class X is declared, auto-attach trait Y and implement Z")
or similar.
But that doesn't preclude me from wanting to support various external
libraries out-of-the box without manual interaction of the users. Which
is what this RFC solves.
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
Bob
