Hi Larry, In my opinion, one of the core assets of PHP is that it contains relatively few syntactic sugar compared to some other languages, e.g. C#. Maybe it's just me, but I believe it makes the code written in PHP easier to read. And I think this is what we should optimize for. Not for saving a few lines of code, but for making the code easier to read and understand.
Now, if we had constructor promotion, we should search for properties both on the top of the class and in the constructor. And I agree with Michał, this kind of code can get out of hand of control very fast. That said, I don't think that declaring properties in the constructor is a good idea. It's also because many people (including myself) tend to write static methods first (I mainly use them as named constructors), so we'd either lose track of properties declared in the constructor or have to force a code style that puts the constructor to the top. Also, some IDEs (but PHPStorm for sure) can generate the constructor very easily from the declared properties. Speaking about the evaluation of "Write-Once Properties" and "Compound Property Visibility", I disagree in some regards. I'll start with the less important one: > Because the write-once state is preserved across cloning, it makes > Evolution worse. I think it's quite expected that properties won't be writable after cloning. That would be a very bad design otherwise. That's why I think your real problem is the opposite: that currently the clone operator is not prepared for this change. That's why I missed the "Rust-like cloning" (or the other clone variant that I presented in the "write-once property" thread) as the solution of the "Evolution" problem of "write-once" properties. My other problem with the evaluation of the "Immutability problem" is that it suggests that immutability is only an external concern, and it isn't a thing in the private/protected scope. Why do you think so? Currently (unfortunately) visibility is the only thing that can at some extent (in external scopes) control mutability in PHP. However, if we look at the problem from the type system perspective, visibility has nothing to do with it: we won't have any guarantee that a property is immutable even if we make it private. To be honest, my impression is that most of the problems you list (e.g. verbose constructor, bean problem, or even property accessors) mainly boil down to the verbosity of PHP (or the "visual debt" problem how some people calls it). As I wrote in the first paragraph, I don't think it's a bad thing. For example, if we had "compound property visibility" then we could separate read/write visibility of properties without using getters/setters (I think this is what you also wrote). If we had property accessors then besides the separation of visibility, we could have materalized properties or properties that validate themselves. Probably the syntax would become more concise, but effectively we would make methods from the properties. But I don't understand why is would be a good thing to have two types of methods? How should we decide if we should use normal methods or property accessors? I think the current situation is much better: use getters and/or setters to separate visibility of properties, and perform validation in setters if you need it. And I I still don't think that property accessors would solve the main use-case of "write-once" properties. Cheers, Máté
