Re: [PHP-DEV] Class Extension

Le 08/07/2026 à 14:07, Michael Morris a écrit :
>
> On Wed, Jul 8, 2026 at 1:08 AM Holly Schilling 
> <[email protected]> wrote:
>
>     Following the discussion in Discord yesterday, I started working
>     on the feasibility of implementing class extensions. I believe
>     I’ve proven out the concept and viability of it in a 2-phase
>     approach using an extension syntax similar to that of Swift.
>
>     Before I go into much more detail, what is the general interest in
>     adding this to the language?
>
>
> We have inheritance (extends keyword, parent / child classes)
> We have traits (an implementation of multiple classes taken from Ruby)
>
> Looking at Swift's extension syntax I fail to see anything it adds not 
> covered by the above.


I think that Swift's extension system goes the other way round: the 
class itself doesn't declare its extensions, but they are declared from 
userland.

It's similar to how Rust's traits system can allow extending other types 
(though there's kind of a safeguard to avoid extending nonsense) , you 
can check it there: https://doc.rust-lang.org/book/ch10-02-traits.html


PHP with inheritance goes this way:

- Declare Class A
   - Class A internally defines which class it inherits from
   - Class A internally defines which traits it uses
- Everything is now defined for Class A and its structure is finite as 
of the end of its declaration


With an "extension" system, it might go this way:

- Declare Class A
   - Class A internally defines which class it inherits from
   - Class A internally defines which traits it uses
- Class A is defined, but extensions can update it somehow.
- An extension is later declared for Class A: it can customize the inner 
structure of Class A, like new traits or implemented interfaces
- Maybe (depending on how the RFC goes) other extensions can be declared 
later, in order to customize other things.


Conceptually, I'm not against it, but just like Michael said: I can't 
find use-cases that would be better than what we actually have. 
Extending a class "from the outside", whatever the way to do it, implies 
that a new safeguard has to be added. We could use the "final" keyword, 
but "final" is not at all the same thing as "no extension allowed": a 
class could be declared as not-final while still disallowing 
extensibility from the outside. That's the case when you have a 
non-final class but some of its methods are "final". Disallowing 
extensibility would require an entirely new keyword for that, and it 
adds another burden to code maintainers, especially if extensibility is 
opt-out.


So, IMO, such RFC should contain this:

- Thorough examples of the actual problems it solves for package 
maintainers and application developers
- Clear views on how extensibility impacts the current ecosystem (I 
guess it shouldn't have any impact on Composer and the autoloading 
system, because if it's similar to Swift, an extension should just 
behave like a class in terms of autoload, but I might have not thought 
about it completely)
- Extensibility must be either opt-in by design, or opt-out by design, 
but the decision must be made **after** having analysed the impact on 
the ecosystem. I can't imagine extensibility being opt-out and people 
starting to wildly override frameworks core classes. (yeah, I'm talking 
about some Laravel nerds that tend to bend and break fast (pun intended))
- Extension points must be defined on both the extender and the extended 
structures. Like, for example, making sure it's impossible to extend 
something that's "final" by default, but making a non-final structure 
being non-extensible should also be possible. That's part of the concept 
of encapsulation in general, but it also respects the Open/Close 
principle (from SOLID) and several other programming practices that make 
sure we don't do bullcrap in all codebases. And trust me, PHP is already 
full of bullcrap, so adding more isn't a good idea at all. PHP hasn't 
become "more and more strict" over time for nothing... and still, that 
strictness is opt-in (by the eyes of PHP, not from framework 
maintainers, which can be seriously opinionated).


Hope this helps :)