> Please don't top post. This is a bottom-post-centric list. Can you please tell me what mailing client you use and what should I?
> if we were designing the language today we would do it very differently. This reminds me working with legacy code in the team which says to write the code in the style in which the project is written. You are trying to make your code more maintainable and readable, decompose your functionality, define clear pre and post conditions. Then comes time for code review and teamlead orders you to throw everything away and write the same legacy as they do because project is written this way. PS. No more do I work in this team. Can you please explain what prevents us from doing the best (like if we were designing the language today) for new features now? 1) Dollars in PHP > Variables in PHP always begin with $. For all time, Always. Yes, but let's not confuse variables (which by definition can be rewritten) with values that can get it's value only once. Almost every time we encounter $ sign in PHP, we can change it's value either as a $property or $variable. All the time we encounter "immutable descriptor for value" (fancy name for not-variable) without dollar sign, it can't be changed. I am talking about constants. 2) Object constants > Objects do not have constants. Classes have constants. Yes, objects do not have constants, but may have `readonly` properties which use constant-like syntax because they can't be ever changed. I don't understand why you name it constants if it is not. > Introducing object-level constants is potentially confusing. Yes, introducing constants may be confusing. Introduction of `readonly` properties with dollarless syntax is very logical. 3) Constants and Properties > Constants shouldn't be set even once. Properties can be, but properties have $ on them. Again, dollar sign is used for mutable value descriptors. Constants don't have dollar sign and are not overwritable. Readonly properties should not have dollar sign because they are not overwritable as well. 4) Reflection part doesn't seem to be complicated here > Are they still properties according to reflection, or are they something else? According to reflection, these are properties. > What would reflection do with these object constants? The reflection part should remain the same as it is with current RFC so that `ReflectionProperty::isReadOnly` is added as well as `IS_READONLY` flag added to the modifiers list. > Can I enumerate mutable properties and constant properties together or separately? Why would you need to enumerate them separately? All of them are properties by definition. > 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. We are in the programming world. In PHP if someone gets undermined, he will know what he did wrong right in a few seconds. After blowing up (if this will ever happen), programmer will write the code with understanding how and why it works this way. On Fri, Jul 16, 2021 at 7:14 PM Larry Garfield <la...@garfieldtech.com> wrote: > 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 > >
