Re: [RFC] Never For Argument Types

> On Aug 15, 2021, at 7:06 PM, Alexandru Pătrănescu <drealecs@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.ledoux@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