> On Nov 7, 2025, at 13:54, Larry Garfield <larry@garfieldtech.com> wrote:
>
> Languages with implicit interfaces like Go also go (no pun intended) "all in" on it.
> All methods on an object are defined externally, possibly not even in the same file. The whole
> standard lib was built on that model from the ground up. That's not the case in PHP.
>
> I've been pondering extension functions for some time, and have kicked the idea around
> with John before. (I would do it as functions, a la Kotlin, not as a secondary class, like Rust.)
> Autoloading and efficiently determining that you need to call an extension are the key stumbling
> blocks (though my stance on autoloading at this point is "we've got opcache enabled 100%
> of the time, we have things like FrankenPHP, just front-load the file and move on with your life).
>
> 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.
>
> --Larry Garfield
Opting out would both be weird, and from a practical standpoint, is unreasonable to ask of userspace
developers.
For correctness, every potential implicit interface match would have to be explicitly declared as
non-comforming in order to be correct. It's both very noisy and does not scale. From a library
perspective, it's impossible: a library class can't possibly declare all the possible
does_not_implement conformances because the entire universe of interfaces that might overlap its
shape can't be known.
A pathological example might look something like:
```
class DeckOfCards
implements Shuffleable, \Deck\Drawable
// We don't actually import any of these, but we have to explicitly deny them because
otherwise it will cause problems in end-user code
does_not_implement \FooGraphics\Drawable, \BarGraphics\Drawable, \ZodGraphics\Drawable,
\GameEngine\TieInterface, \BarGameEngine\DeckDrawable, \Vehicle\Drawable
{...}
```
There's also a problem point with any code that calls get_declared_classes() and
filters by instanceof SomeInterface. Now all that code is potentially broken (if
implicit conformances don't meet contractual requirements). Would we need to add an
implicit/explicit/either option to is_a() to make userspace able to correctly reason
about types? Are there other cases where implicit conformance needs to be treated differently than
explicit conformance?
Importing a package that has an implicit type would basically have to come with a warning,
"don't make your classes look like this interface or else things might break".
And I'm sure someone would also find a creative way to abuse the trivial case, implicit
interface AnyObject {}.
-John