On Mon, May 29, 2023, at 11:22 PM, Máté Kocsis wrote: > 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.
My point is, rather, that if we want to avoid having multiple syntaxes (which is valid), the existing named-args syntax and behavior already more than adequately covers all bases. > 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. Has the "if you need a variable name/number, use an array" been a problem for named arguments? I've not seen it been one. Has anyone else? You cannot use an expression as a function argument name today, and... no one seems to mind. Using an array in that rare edge case is fine. I think we agree that the most common case by far will be a fixed, small set of statically-named properties. So we should optimize for that case, which is the named-args style. >> 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. Except that named-args style gives us the better alternative today, with known, pre-existing syntax and semantics. > 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()? Not a specific one off hand. It's more a conceptual question. `with` has more contextual awareness than __clone(), so it should have "first crack" at the operation, so that if necessary it can make changes that __clone() can then respond to. The inverse doesn't make sense. The only reason for `with` to come after would be to allow `with` to "override" or "undo" something that __clone() did. Generally speaking, if you have to undo something you just did, you shouldn't have done it in the first place, so that's a less compelling combination. This one isn't a deal breaker, but we should be sure to think it through as it's kinda hard to reverse later. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
