Hello,
Sorry, but I've got another idea. I already validated it with ChatGPT who
labeled it spicy. After clarifying some misunderstandings, they updated the
label to "heretical". I hope you'll find it exciting as well.
As you're all aware, classes in PHP are literally unusable and impossible to
implement. Id est
class A {}
class B implements A {} // this is not allowed in PHP
class C {
use A; // this is also not allowed in PHP
}
However, under the hood both interfaces and traits are classes, just with
different vibes. I mean flags. The limitation feels almost artificial:
https://github.com/php/php-src/blob/334d9bbc09e37d6f66dde23988df7d7299dc6f19
/Zend/zend_inheritance.c#L2248-L2252
https://github.com/php/php-src/blob/334d9bbc09e37d6f66dde23988df7d7299dc6f19
/Zend/zend_inheritance.c#L3554-L3558
I suspect it would be quite possible to drop these limitations, so the main
question seems to be - are these limitations useful? Or would it be usefuler
to have classes without such limits? Let me elaborate:
## Part A. Implementable classes.
Idea: allow using normal classes in the interface list.
class A {}
class B implements A {}
The result would be that B gets checked whether it satisfies the public
interface of A. From there on B gets treated as a subclass of A: `(new B)
instanceof A` is true and instances of B satisfy an A typehint.
These days many projects, libraries and frameworks add a bunch of interfaces
that each correspond to a single class (and mirror it's public signature)
that might be replaced with a different implementation. Some libraries
define a hundred interfaces while the consumer projects use at most a few of
those replacement opportunities.
These would make such just-in-case interface definitions redundant as the
class itself could be used as the interface. In otter words: why make an
interface if you've already defined the interface in that class right there?
## Part B. Usable classes
Idea: allow using normal classes in the trait list.
class A {}
class B {
use A;
}
The result would be that B gets the guts of A, just like if A was trait.
This would simplify reuse and composition and reduce the need for
workarounds (aka design patterns).
Together they would simplify making libs that add features to your models or
something like that. E.g. you can do this without splitting them into a
trait and an interface and duplicating the signature.
class YourModel implements SomeFeature {
use SomeFeature;
}
## Bonus feature
You essentially get multiple inheritance free of charge as the conflict
rules for both interfaces and traits are already well defined.
class DoublyInherited implements A, B {
use A, B;
}
As ChatGPT told me yesterday: Sure, this blurs the lines between classes,
traits, and interfaces. But so does PHP in general.
BR,
Juris
