Hi Michał and Larry, As Tim has already clarified, using literal strings in the left-hand side of "clone with expressions" won't cause any issues for IDEs and static analysers to identify the correct property. I got rid of the shorthand syntax from the proposal because it is not strictly required (since it has an equivalent alternative), and I acknowledge the fact that there are certain people who don't want to have two syntaxes to express the same thing. If it turns out that we really want to have the short-hand syntax as well, we can always add support for it later.
Conversely, using the named arguments style syntax (what future scope calls > a shorthand, which I don't think is accurate as it's nearly the same amount > of typing) I'm just using the same wording as Nikita used in his named argument RFC. Please take a look at the following section: https://wiki.php.net/rfc/named_params#shorthand_syntax_for_matching_parameter_and_variable_name Especially this sentence is important: If I wanted to put these ideas into a general framework, I think one way to > go about this would be as follows: > - Consider identifier: $expr as a shorthand for "identifier" => $expr. Even though the shorthand syntax is only 4 characters shorter than the normal one (including the missing space before the colon), for a typical property name which may be 4-8 characters long (I guess), it's a significant reduction of typing. That approach, taken now, gives us all the flexibility people have been > asking for, reuses the existing named arguments syntax entirely, and is the > most refactorable option. > Your suggestion is very interesting/promising... However, I'm a bit worried that if I only supported the "identifier: expression" syntax for "clone assignments", and I required people to pass an array (or splatted array) instead of the "expression => expression" syntax, they would start complaining why they cannot directly use expressions as property names... That's why I think all the alternatives are useful on their own, but only the "expressions => expression" syntax is vital, since all the other use-cases can be written like this. > Additionally, the current "property names expression" section shows a very > odd example. It's recloning the object N times, reinvoking the __clone > method each time, and reassigning a single property. If you're updating > several properties at once, that is extremely inefficient. Dynamic > property names are not the solution there; allowing the list to be dynamic > in the first place is, and that should not be punted to future scope. > I'm aware that it's currently inefficient, but it's the case only when you want to update a dynamic list of properties. In my opinion, you update a fixed set of properties most of the time (e.g. Psr\Http\Message\ResponseInterface::withStatus()), and it's only a rare case when you need more dynamic behavior. That's why I believe it's not a huge problem to keep cloning objects unnecessarily until we add support for the stuff mentioned in the future scope section. I am also confused by the choice to make __clone() run before with with > properties. I would have expected it to be the other way around. Can you > explain (in the RFC) why you did it that way? That seems more limiting > than the alternative, as you cannot forward-pass information to __clone() > this way. > To be honest, the current behavior seemed like the natural choice for me, and I didn't really consider to execute the __clone() method after the clone assignments. Do you have a use-case in mind when you need to forward-pass information to __clone()? Regards, Máté
