On Tue, May 17, 2016 at 4:14 AM, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 17/05/2016 11:55, Jesse Schalken wrote: > $id > |> StringList::decode($$) > |> array_replace($$, $replace) > |> StringList::encode($$) > |> $id; > > > Sara, what do you think of this tweak, and my subsequent suggestion that the > pipe should only be usable as a *statement*, not an *expression*? > I'm not strictly against it, but I'm not a huge fan. Primarily, it's the statement-only restriction that bothers me since (apart from control flow structures), most constructs in PHP are expressions, not statements, and this feature naturally fits in the composable expressions category, not the top-level statement category. From an implementation standpoint, I'm fairly confident that the patch would be much more complex as a result of enforcing that statement-only requirement.
Meanwhile, if we remove the statement-only requirement, then using "simple-variable" as a signal to switch to expression termination, then we introduce a whole class of bug where a user fat-fingers the $$ token in what SHOULD be another link in a chain expression, but it's not detectable as an error because a simple-var is valid. And one more counter-example: $x |> foo($$) |> $y[$$]; This is no longer a simple var, should that terminate our statement by writing to $y[$$]? Or should that be seen as the next link in a chain where we read the value from $y[$$] (which could well have getter side effects)? I would probably expect the latter, but maybe the former was intended? So yeah, I'm really not a fan. That said, if enough other people chime in that they think these issues are surmountable in "a PHP way", then I'll take a crack at a PR and we can include it in the discussion, but as-is.... I can't quite get behind it. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
