-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[EventDispatcher] Add types to private properties #41924
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Note: One thing I intentionally kept out of this PR was constructor property promotion. Introducing property types would technically enable us to use CPP. However, this is mainly syntactic sugar that makes merges from lower branches for existing classes difficult and would bloat the diff for a PR that introduces property types. If we ever feel like migrating to CPP, that step can be automated well, once we have private properties. |
I'd rather leaving it untyped that adding a wrong type ( |
No, but it does make sure that the property is not null for instance. As I said, I'm not super happy either, but I tried to narrow down that type as much as possible. |
@derrabus I'd still keep it untyped, relying on phpdoc (and the static analysis). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with the type for listener personally
as a rule of thumb, we'd better store closures than callables anyway
here we can't, but we don't call it either
src/Symfony/Component/EventDispatcher/Debug/WrappedListener.php
Outdated
Show resolved
Hide resolved
36961a8
to
bd5556f
Compare
All right, so for future PRs I'll check if I can turn a callable into a closure. |
Next attempt: The DI component: #41928 |
Signed-off-by: Alexander M. Turek <[email protected]>
bd5556f
to
3852fee
Compare
Thank you @derrabus. |
…errabus) This PR was merged into the 6.0 branch. Discussion ---------- [DependencyInjection] Add types to private properties | Q | A | ------------- | --- | Branch? | 6.0 | Bug fix? | no | New feature? | no | Deprecations? | no | Tickets | N/A | License | MIT | Doc PR | N/A Same procedure as #41924, but on a more complex component. Commits ------- 069da20 [DependencyInjection] Add types to private properties
In Symfony 6, we would be able to use typed properties. This is why I gave it a try and migrated all private properties of my favorite component to evaluate how the path might look like and what we have to watch out for.
Why only private properties? Well because adding types here is mostly safe. If I add a type to a protected/public property, I might break existing code that overrides that property.
One important thing we have to watch out for is the uninitialized state that a typed property has until we assign a value to it for the first time. As long as that property is in that state, reading it will trigger an error. However, calling
isset()
is safe and access to those properties can be safeguarded with??
and??=
.An untyped property would implicitly be initialized with
null
and our existing code often relies on that behavior.Another pitfall is the
callable
pseudo-type: PHP does not allow us to assign it to a property. I've usedstring|array|object
instead, but I'm open for better ideas.I used PhpStorm for most of the work, but I needed to adjust the code afterwards. I've searched the code (except the
Tests
folder) for forprivate $
, opened each file and let PhpStorm infer all property types. Findings:= null
initializer.The manual work was mainly look at all the places where a property is accessed and check if an implicit
null
initialization was expected or ifnull
is assigned directly to the property. My goal here was to avoid making a property nullable if possible.I sometimes moved an initialization with a constant value from the constructor to the property declaration to make the initialization more obvious. I think we can backport that if we want to keep the diff small.
What do you think? Shall we go with types properties?