Apologies for the top post, I'll... have to get used to that.
I could see implicit interfaces working in conjunction with extension
functions, if we can figure those out. I'm not sure if they offer much
value without them, given the state of PHP. It would basically mean you
have to opt-out of a type rather than opt-in, as now. That could get...
weird.
I'm not sure I understand why the value on this is low without extension
functions or why we would need the ability to opt-out. In my day to day, I
saw this most commonly being utilized for:
-
I'm working with a class that is probably oversized, but I only care
about a thin part of the functionality, but I don't have a clear way to add
an interface to that class which defines the contract I need. Using an
implied interface in this case helps me thin out the contract to what I
need, and that makes testing much easier as I can mock only those relevant
functions. This would be resolvable with the original class being better
designed, but that's not always an option. On the testing side this is kind
of made easier with partial mocks, but those can trigger all sorts of side
effects that aren't much fun to work with in my experience. -
The joining of common interfaces for easier introduction of
interoperable interfaces, thinking about PSR-11 not tackling the
configuration of entities, or how some of the interfaces look on the
symfony cache packages. -
Clearer definition of "duck-typing" like behaviors into the function
signature. This is stuff we already see in PHP (if (method_exists(<bla bla>)), but to me it would improve clarity if these requirements were in
the parameter and property definitions, instead of in the function body.
All 3 of these (at least to me) seem improved with this path and high
value, but I'm worried I may be missing something.
To me in these cases, if someone bumps into mistaken typing, that's
generally on the caller. Explicit interfaces do guarantee that anyone
opting into that contract is doing it for the intended reasons, but if
you're working with an implicit interface it becomes the function caller's
responsibility to ensure they are making wise decisions on what gets passed
in. I don't think this is a new problem set since it exists with the
current duck typing patterns, all we've done is more clearly defined our
expectations on what functions exist without a lot of manual
method_exists/property_exists
- Spencer