> On Nov 7, 2025, at 13:54, Larry Garfield <[email protected]> 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
