Hello internals,
Based on a few discussions I've had recently, my team and I couldn't think of any reason why we shouldn't have properties on interfaces as it is common for these to be specified in doc blocks currently. Timing-wise, this lines up well with dynamic properties being depreciated.
I've thrown together a very quick POC, there are many tests and examples of how this could look.
https://github.com/php/php-src/compare/master...Humni:php-src:feature/rfc-interface-properties
Some of the key architectural decisions:
- interfaces can implement the same property (exact type match only)
- interface properties must be public
- interface properties can't be static
- interface properties can be readonly
Open to feedback from everyone on this - keen to get the ball rolling quickly on it!
Kind Regards,
Nick
Hello internals,
Based on a few discussions I've had recently, my team and I couldn't
think of any reason why we shouldn't have properties on interfaces as
it is common for these to be specified in doc blocks currently.
Timing-wise, this lines up well with dynamic properties being
depreciated.I've thrown together a very quick POC, there are many tests and
examples of how this could look.https://github.com/php/php-src/compare/master...Humni:php-src:feature/rfc-interface-properties
Some of the key architectural decisions:
- interfaces can implement the same property (exact type match only)
- interface properties must be public
- interface properties can't be static
- interface properties can be readonly
Open to feedback from everyone on this - keen to get the ball rolling
quickly on it!
Interface properties are already included in the Property Hooks RFC, which should be going to a vote soon-ish. We hope it passes, of course. :-)
https://wiki.php.net/rfc/property-hooks
--Larry Garfield
On Sat, May 27, 2023 at 6:24 PM Larry Garfield larry@garfieldtech.com
wrote:
Hello internals,
Based on a few discussions I've had recently, my team and I couldn't
think of any reason why we shouldn't have properties on interfaces as
I wouldn't support this, personally. The reason interfaces in most
languages which have this concept don't support defining properties is
first because they are generally seen as an implementation detail rather
than a promise about supported behaviour and second because interfaces are
essentially an alternative to multiple inheritance. At the point you're
mandating fields as well as method signatures, you're barely one step away
from an abstract class anyway. If you still want to combine interfaces with
shared properties or default implementations, we already have traits for
that purpose. In PHP, two interfaces which define the same method signature
can be implemented by the same class, which is at least a little bit iffy
in itself. It becomes even more problematic if multiple interfaces can
define the same property, because you now don't really know
what, conceptually, that property refers to.
Interface properties are already included in the Property Hooks RFC, which
should be going to a vote soon-ish. We hope it passes, of course. :-)
For the reasons I've said, I'm not loving the interface part of the
property hooks RFC either, to be honest, though I do support the broad
feature. I can appreciate that when an interface is used with the hooks,
it's more akin to saying an interface is defining setSomething() and
getSomething() methods rather than defining a property directly - but it
feels like it will encourage writing interfaces which break encapsulation.
-Dave