Skip to content
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

PHP 8 Immutable Attribute #7

Open
svnldwg opened this issue Nov 3, 2020 · 3 comments
Open

PHP 8 Immutable Attribute #7

svnldwg opened this issue Nov 3, 2020 · 3 comments

Comments

@svnldwg
Copy link
Owner

svnldwg commented Nov 3, 2020

PHP 8 will enable attributes. PhpStorm 2020.3 introduces an immutable Attribute: https://blog.jetbrains.com/phpstorm/2020/10/phpstorm-2020-3-eap-4/#immutable

The immutable rule should detect this attribute and ensure immutability.

@staabm
Copy link

staabm commented Feb 12, 2022

The phpstorm immutable attribute allows readonly access to public properties of immutable classes.

as I read the unit tests of this package, it seems public properties are per se disallowed… wdyt about allowing read-only access from outside, even for public properties on immutable classes?

@svnldwg
Copy link
Owner Author

svnldwg commented Feb 12, 2022

@staabm interesting question, I wasn't aware that phpstorm handles the immutable attribute that way.

Immutability how I understand it means that an object is immutable in terms of it is simply not possible to change the object after its initialization. Public properties make objects mutable, they can change, even if that never actually happens. That's why I think it's dangerous to use public properties if immutability is the goal. I don't want to have to rely on my IDE or other tools to make sure the object isn't actually mutated, but the immutability should be ensured by definition.

@staabm
Copy link

staabm commented Feb 12, 2022

interesting question, I wasn't aware that phpstorm handles the immutable attribute that way.

I wasn't aware of it either, but I learned it from the url you posted in the initial description :-).

tbh we are happily relying on our dev tools and static analysis and therefore love to use public read-only properties.
we don't like getters/setters in our value-objects

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

No branches or pull requests

2 participants