Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129626
Feedback-ID: id5114917:Fastmail
Message-ID: <24592968-1702-4607-bafe-c6cfa437e818@rwec.co.uk>
Date: Tue, 16 Dec 2025 20:47:26 +0000
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Context Managers
To: internals@lists.php.net
References: <CAJp_myV9+kxx-eA+cja-Fu5dJhDZgzhgpBpiZFWqqW-_zrNreQ@mail.gmail.com>
 <70A79513-5503-467E-BC6F-2B0494A3EBB9@benramsey.com>
 <CADK1yXJgPsZJ5+qepDotrMMtRm8TtG95wS7UNpvd8D=Pm-+BOQ@mail.gmail.com>
 <D8927CEA-3D00-4ECF-807B-7C2C96C5B582@rwec.co.uk>
 <CADK1yXJUt3OLExBT5462mHu_vaxyRuUTKcVYF_kbwY04_y8TJA@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CADK1yXJUt3OLExBT5462mHu_vaxyRuUTKcVYF_kbwY04_y8TJA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 16/12/2025 11:25, Deleu wrote:
> My conclusion here is exactly the opposite of yours because this 
> explanation makes `as` even more symmetrical now.


I haven't exactly reached the "opposite" conclusion. If anything, I've 
now reached the conclusion that "as" and "=>" are both equally ambiguous 
and easy to misinterpret.


> As you've mentioned `foreach(new MyIterator as $iterator)` is not how 
> it works. An iterator *produces a value* that is assigned to the 
> variable after `as`. Symmetrically, `using(new ContextManager as 
> $context)` the ContextManager is also producing a value that is 
> assigned to the variable after `as`. The only difference is in the 
> keyword: foreach will loop, but using will not loop since 
> ContextManager is not an iterator.


That is certainly how I read it, having already been primed by mentions 
of iterators in the Python design document.

However, Tim pointed out (as you say, it came up in a different thread) 
that the "each" is doing important work in the phrasing "for each ... 
as". (It occurs to me that PHP used to have an actual function called 
each(), which gave you an item from an array.)

Without that hint, the "X as Y" could easily be misread as meaning that 
X and Y are the same thing.

In plain English, "using the screwdriver as a hammer" means the 
screwdriver and the hammer are the same object. In PHP, "use Foo as 
Bar;" means Foo and Bar refer to the same class.



On 16/12/2025 15:59, Larry Garfield wrote:
> Second, I find it fascinating that there's so many different mutually-incompatible spins on what => means.


I think we're all engaging in a lot of post hoc rationalisation for a 
bunch of syntax that's evolved haphazardly, with multiple inspirations.

I was particularly amused by this:

> For the arrow function, it's kind of implied in the name ARROW 
> function that we would need a syntax in the lines of `fn () =>`.

It makes me imagine a Computer Science researcher named Dr. Arrow, who 
invented a new kind of function, but didn't know how to write it until 
their friend pointed out that their name would make a suitable pun.


In reality, I suspect there are at least two lines of origin:


1) The key => value syntax for arrays is pretty clearly inspired by 
Perl, which was far and away the most popular web programming language 
in the early 1990s.

In Perl, it's called the "fat comma", and (a => 'b') is actually a 
synonym for ('a', 'b').


2) Using some form of "args arrow expression" for lambda functions comes 
ultimately, I suspect, from Functional Programming languages. The "=>" 
in match statements can probably be traced to there as well.

Notably, exactly what arrow is used varies from language to 
language. CoffeeScript (created in 2009) has both "(args) -> expression" 
and "(args) => expression" with different semantics; 
JavaScript/ECMAScript basically adopted the "=>" version in 2015. 
Meanwhile, C# added "(args) => expression" in 2007; Java added "(args) 
-> expression" in 2014. Hack used "(args) ==> expression" but needed an 
ugly parser implementation, and an early PHP proposal for "(args) ~> 
expression" was rejected, so we ended up with "fn(args) => expression" 
instead.


Ultimately, the thing that all the uses of "=>" have in common is some 
reason to want an ASCII representation of an arrow, and the need to fit 
it into the constrained space of an existing grammar.

The same is basically true of "as" - it's a nice short English word, 
with multiple meanings. That's a blessing and a curse: a blessing, 
because we can reuse it in different contexts without reserving more 
words; a curse, because people might have different intuitions about 
which meaning was intended.


Which brings me back to where I started this e-mail: my conclusion is 
that neither "as" nor "=>" is clear and unambiguous. We could probably 
pick either, and people would get used to it; or we could try for 
something better.

Regards,

-- 
Rowan Tommins
[IMSoP]