> On Aug 15, 2021, at 7:06 PM, Alexandru Pătrănescu <dreal...@gmail.com> wrote: > > If I see an interface that was created just so it can be implemented by > multiple classes but the caller doesn't use the interface but it uses the > actual classes, I call it out as that is the wrong abstraction and the > interface should just be removed. > > Your example with ArrayAccess is similar with this; when using it, you know > exactly what implementation you have. The interface is not helping here > related to polymorphism but it is actually required to allow a language > construct related to the engine itself, to translate accessing an object > with the same syntax as for an array. > > If the 4 functions would have been magic methods, without an interface, you > would not have this problem.
That is very insightful. It seems that back when PHP only had a hammer, PHP used a hammer. But now that PHP has a better tool for the job maybe PHP should change course? More specifically, since ArrayAccess is primarily being used as a class annotation and not to enable polymorphism maybe the best course of action would be to deprecate having `ArrayAccess` the interface being an annotation and to instead having `#[ArrayAccess]` the attribute tell PHP to allow indexing instances of the class like an array? > On Aug 15, 2021, at 6:22 AM, Jordan LeDoux <jordan.led...@gmail.com> wrote: > > 2. Interfaces have more purposes than just standing in for classes in a > type hint. Interfaces also guarantee an implementation. Correct. Which is why interfaces that allow for non-specific types — e.g. `mixed` or `never` — weaken that guarantee[1]. If `never`-parameter interfaces were to exist then code that passes a parameter to a `never`-parameter method would first have to check via reflection if the type if wants to pass will be accepted. That nullifies the guarantees of an interface. I think the reason for envisioning `never` as an option to address the concerns it attempts to address is the unfortunately ramification of, as Alex identified, the choice to use an interface as a signal to provide language specific behavior to a class rather than to enforce polymorphic behavior. So rather than double down on features based on leaky abstractions better to backtrack and correct the original sin IMO. -Mike
