Re: [RFC] Context Managers

> > First, yeesh, where were y'all 2 weeks ago? :-P > I searched for the as vs => discussion on the current thread (ref: https://externals.io/message/129077) and it didn't exist until now. Then I found the discussion happened on the Examples comparing Block Scoped RAII and Context Managers (ref: https://externals.io/message/129251). I wasn't following that discussion because I thought it was mostly about comparing both implementations and taking knowledge from it. I didn't expect *that* to make this RFC to change without it being discussed here. > Second, I find it fascinating that there's so many different > mutually-incompatible spins on what => means. As argued in the > short-functions and auto-capture-closure RFCs from a few years ago, => in > nearly all cases currently means "evaluates to." > > $arr = [ > 'a' => 'A", > 'b' => 'B', > ]; > > $arr['a'] // This "evaluates to" A > > match ($foo) { > 'a' => 'A', > 'b' => 'B', // The 'b' case "evaluates to" B > }; > > fn($foo) => 'bar'; // This function "evaluates to" bar > > foreach ($arr as $k => $v) {} > > The last is a little bit inconsistent, but can still be read as "$k, and > the thing that $k evaluates to." > I think the problem might be less about the true meaning of => and more about the context that it applies to. You can see that in 3 cases of the arrow it involves some sort of key/value pair (2 array scenarios and 1 match/case). In the case of arrow function, like I said before, arrow functions are kind of a standard that stand up on their own. And even then, the "evaluates to" is only partially because in arrow functions the evaluation does not take immediate effect, it is parsed into a Closure that needs to be invoked. For instance: ``` $array = [ 'key' => throw new Exception('Stop'), ]; ``` Here, the arrow evaluates to an exception that is immediately thrown. ``` match ($foo) { 'a' => throw new Exception('Stop because of A'), 'b' => throw new Exception('Stop because of B'), }; ``` Here, the evaluation is more loose and it only takes effect when there is a match, but it does take effect. ``` fn () => throw new Exception('Stop'); ``` Here, the evaluation never takes effect if the Closure is not invoked. In these 3 cases, we can see each having its own evaluation rule: immediate, immediate only for the match, and delayed. If I were to put into words, I'd say: array keys: evaluates to match: evaluate to the matched key arrow function: parse the syntax, does not evaluate to. ``` foreach ($arr as $k => $v) {} ``` Here I don't see it only as a bit inconsistent because it's not really evaluating anything anymore. It is assigning a value. And this is where it blows up for me. The first 3 cases we can argue semantics and point of views, but they are minor nuances. Still, they're all cases where something on the right is being evaluated for a reason on the left. On foreach, $v stands on its own. It's not affected / impacted / dicated / evaluated towards the left at all. It's not a bit inconsistent, it's completely different. And the syntax for using () is largely similar to foreach, which is why it should use as and not =>. foreach ($iterator as $key => $value) using ($contextManager as $context) We can see that the only place where arrow ("evaluates to" / =>) is used inside an instruction is in foreach and the syntax is split away from the array itself because the keyword as is separating $k => $v from the $iterator. I can totally see an argument for: using (new ContextManager as $contextManager which evaluates to $context) using (new ContextManager as $contextManager => $context) Here, the return of enter would be [$this, $context] and the syntax falls into place with a symmetry from foreach. I wouldn't strongly push for this syntax because the following also works using ($manager = new ContextManager as $context) In any case, I don't have a vote and I really like the RFC in general. With proper IDE support, I'm sure we will all get used to =>, but from where I stand that's going to be really awkward for the PHP syntax. -- Marco Deleu