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?
On Wed, Jul 8, 2026 at 1:08 AM Holly Schilling <holly.a.schilling@outlook.com> 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.
On 8 July 2026 06:08:42 BST, Holly Schilling <holly.a.schilling@outlook.com> 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?
Hi Holly,
Can you give a brief summary of what the feature is, and how it would apply to PHP, for those of us who aren't familiar with Swift, and haven't seen the Discord discussion?
Thanks,
Rowan Tommins
[IMSoP]
Le 08/07/2026 à 14:07, Michael Morris a écrit :
On Wed, Jul 8, 2026 at 1:08 AM Holly Schilling <holly.a.schilling@outlook.com> 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: Defining Shared Behavior with Traits - The Rust Programming Language
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 
On Jul 8, 2026, at 14:07, Michael Morris <tendoaki@gmail.com> wrote:
On Wed, Jul 8, 2026 at 1:08 AM Holly Schilling <holly.a.schilling@outlook.com> 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.
Traits and extensions approach a similar problem from the opposite direction. Where a class uses a trait to add functionality, instead, an extension declares that it has added functionality to a class (or interface).
Besides allowing one avenue for default implementations for interface methods, extensions would also allow for polyfills for class methods and properties that can be hooked. For example, PHP 8.5 adds the (sadly not documented yet!) `Dom\Element::getElementsByClassName()` and `Dom\Element::insertAdjacentHTML()` methods. If PHP 8.4 already had extensions, then extensions would have made it possible for a userspace library to provide an implementation for those methods on PHP 8.4.
In the hypothetical case where we have method calls on scalar types, extensions could also be used as a means of adding methods to those types (either in userspace, or internally or in php extensions).
-John
Hey Holly,
Interested in some sort of solution! – Cheers Nick
On 08.07.26 12:08, Holly Schilling 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?
I like how extensions in Swift allow to organise code!
If we ignore implementation details and ownership it’s pretty similar to what we have with traits. In PHP, what would be the benefit of extensions over traits? One thing that comes to my mind is that traits can be used by whatever chooses to add it (back to ownership). Good one, but what else? If ownership is the only concern then maybe a small addition to traits could achieve the same?
trait Foo
{
for Baz\Bar::class; // inverse of "use" to limit usage
}
class Bar
{
use Foo;
}
Brings conflict resolution for free; and I think it would be cheaper than yet another class-like thing. Maybe also feels more php-ish since we already have the trait concept?
Before I go into much more detail, what is the general interest in adding this to the language?
hello,
On Wed, Jul 8, 2026, 12:11 PM Holly Schilling <holly.a.schilling@outlook.com> wrote:
Following the discussion in Discord yesterday, I started working on the feasibility of implementing class extensions.
For one, I read only internals and github. I keep seeing “we talked on discord” but there is no reference whatsoever to a php.net’s discord anywhere i searched for.
so maybe I would suggest to be a tat bit more descriptive first here too?
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?
reading the thread, I feel both swift and you aim to the same goal, some parts use different approaches but as I am not a user of swift, it may be nicer if you could work together, if desired?
Pierre
@pierrejoye
For one, I read only internals and github. I keep seeing “we talked on discord” but there is no reference whatsoever to a php.net’s discord anywhere i searched for.
so maybe I would suggest to be a tat bit more descriptive first here too?
Yes, this has not been as public of a discussion as it should be, so please allow me to share some more details here for you and the rest of the Internals community.
There are currently 3 RFCs comprising 3 phases and feature sets to build for extensions.
extension \DateTimeImmutable {
public function isWeekend(): bool {
return in_array((int)$this->format(‘N’), [6, 7], true);
}
}
~~~
var_dump((new DateTimeImmutable(‘2026-07-11’))->isWeekend()); // bool(true)
~~~
extension string {
public function length(): int { return strlen($this); }
}
var_dump(“hello”->length()); // int(5)
~~~
3. Extension Visibility and Importing: [https://gist.github.com/hollyschilling/dc97ea217302de2f4c9ad7d527aaa65b](https://gist.github.com/hollyschilling/dc97ea217302de2f4c9ad7d527aaa65b)
This adds rules and syntax to be able to import an extension without using `require_once` (or similar).
First, the autoloader needs extensions to have a name, so we give them a name when declared.
```
```
```
```
// vendor/acme/dom-kit/src/traversal.php
namespace Acme\DomKit;
extension DomTraversal on \DOMElement {
public function firstByClass(string $class): ?\DOMElement { /* ... */ }
}
```
~~~
~~~
Then, as we want to use our declared extensions, we import them with a `use`, similar to normal classes.
~~~
~~~
use extension Acme\DomKit\DomTraversal;
$el->firstByClass('hero'); // resolves here
```
> > 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?
>
> reading the thread, I feel both swift and you aim to the same goal, some parts use different approaches but as I am not a user of swift, it may be nicer if you could work together, if desired?
>
> >
Extension methods allow adding functions to existing classes. As a future consideration, they can also be used to add readonly virtual properties (No setter; No storage). This is purely syntactic sugar, but it can be extremely helpful making code easier to read and increasing code reuse. Think of it as a Trait that you apply to someone else’s code after the fact.
It is also possible to apply an extension to an Interface. While it cannot be used to implement members of the interface, it can make all classes implementing that interface have useful methods.
The other useful feature is that a class may implement its own version of a function and the function resolution will go to the class’s implementation as you might expect.
I hope this helps. The 3 links go to the Gists for each phase and a link from each Gist goes to the implementation for each.
I’m happy to answer any additional questions you or anyone else has as you read through the docs.
Holly