Skip to content

Conversation

@herndlm
Copy link
Contributor

@herndlm herndlm commented May 29, 2022

I thought this makes sense for consistency reasons. It looks like, though, that specifying additional constructors for this rule doesn't change anything. I assume because it's only dealing with unused/write-only/read-only props and doesn't care if it's in a constructor or not.
Does this still make sense then?

@herndlm herndlm marked this pull request as ready for review May 29, 2022 12:02
@herndlm
Copy link
Contributor Author

herndlm commented May 29, 2022

On second thought, if I look at ClassPropertiesNode::getUninitializedProperties again, it might even make sense for this rule to set constructors to []. Then that method won't continue looking for premature property access and for additional assigns (which are related to the constructors). Might be a tiny performance improvement hmm

@ondrejmirtes
Copy link
Member

it might even make sense for this rule to set constructors to []

I agree with that :)

@ondrejmirtes
Copy link
Member

...given all tests will pass with that code, hopefully.

@herndlm herndlm closed this May 29, 2022
@herndlm herndlm deleted the constructors-helper-in-unused-private-property-rule branch May 29, 2022 12:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants