On Fri, Jul 16, 2021, at 6:48 AM, Eugene Sidelnyk wrote: > @Nikita Popov <nikita....@gmail.com> I'm not sure what you mean by saying > this: > > > We're always explicit at the declaration site, it's const FOO, function > foo, class Foo etc > > > Regarding your message > > > Here mutability is decided by single $ character in the declaration, > which doesn't have a particular obvious connection to mutability. > > Yes, that is not really obvious about property mutability when we look at > the code. > I think it is probably better to rephrase it into something like: New way > of properties definition without dollar sign. Not only do we remove dollar > sign, but these properties can not be reassigned. > > Looking from this perspective we are trying to improve code quality and > developer experience. Using immutability (as well as type-hints with strict > typing) makes code less error prone. This should be promoted in the PHP > community. > What I want to say is: good things should be easily done, easier than > things which are more error prone. > > Again, about explicitness and obviousness. > Imagine (just for a second) that all existing properties are immutable by > default. Then someone submits RFC to add mutability for them. It is > accepted to add a new keyword like this: > > ```php > mutable public string $bar; > ``` > > Hence I mean: currently we have one default option (mutable properties) > from 2 options. Why do we need to create such a long keyword just to use > readonly properties (if immutability is better than mutability)? > > Regards, Eugene
A) Please don't top post. This is a bottom-post-centric list. B) As others have said, if we were designing the language today we would do it very differently. I'd likely push for following Rust's example of immutable by default, super strong typing, and a `mut` keyword to poke holes in the immutability where necessary. However, we have ample existing code that cannot be broken, so that limits what we can do. That means adding a readonly/immutable/whatever flag is the only real option, even if it is annoyingly verbose. I can see the logic behind "initialize at runtime constants" which is what you're describing, as an alternative. However, that breaks a ton of existing patterns. 1) Variables in PHP always begin with $. For all time, Always. 2) Objects do not have constants. Classes have constants. Introducing object-level constants is potentially confusing. 3) Constants shouldn't be set even once. Properties can be, but properties have $ on them. 3) What would reflection do with these object constants? Are they still properties according to reflection, or are they something else? Can I enumerate mutable properties and constant properties together or separately? This gets complicated fast. I agree with the point that the verbosity of `readonly` is potentially annoying, but we haven't seen it in practice yet. If it ends up being a problem, then as someone else suggested a more likely solution is a `readonly` flag on the class, possibly with a `mut` keyword on the property to opt it back out, or something like that. Not ideal, but probably the best we could do. Having very subtly different syntax for a very significant behavioral difference in properties seems like a landmine waiting to happen that would only confuse people. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
