Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129614 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 77F391A00BC for ; Tue, 16 Dec 2025 07:09:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1765868985; bh=FL/St42u6Xmt/btb9luRvATCW4TQkwVrKFixaJ7KGw4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=MIasdbLmbZJ6ZPoGCk5+sb9f7NFoYEnnsBUycSZeFjrMATTopi6ogOYUGvQ6moUGi aQOXHMv3HuzlosOYkQPJh1lnljiKN3AojimZax5wNu5M82gvx6rTFdRSEz+mQ4OCoJ 9jtt29OW/T4b6aZF//AsLri85mv2pLoGSPxQ30duSGY2/BVu+Xw2PTKcxqzbh7ulhJ nEy80shhTLQ/gT4+9ECVy0AQq1di/FFPMVwJ5kc+9tUs98TJ/RP5DgL68Vwm6EgV/N AlZbt4XnfCcBqMNZU6LdZ0V6LFrUzk10qqMt5CD1Cq+0uDfFnSQRpbzJGhc7c1Z6ln QGufy/Dd5Qfxg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id AC93B18004C for ; Tue, 16 Dec 2025 07:09:40 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: * X-Spam-Status: No, score=2.0 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,T_SPF_TEMPERROR autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-yx1-f41.google.com (mail-yx1-f41.google.com [74.125.224.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 16 Dec 2025 07:09:40 +0000 (UTC) Received: by mail-yx1-f41.google.com with SMTP id 956f58d0204a3-63fa0ddcc66so659840d50.1 for ; Mon, 15 Dec 2025 23:09:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765868975; x=1766473775; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6dNPZ/bieSxq1oY8+0BuXs/EOgOdL2p+iOrnlU2Ygm0=; b=dwcfYxdBPvjuhiMP0BePGsUTjB7nKhHa9zLRjMtZzuKuSsn0nR05HnKJQqRzLJe/nP SC9QmAIoTyWxqn/YC08sEVPesEBWYXlLJsKQMIPI23i3O5o5VzAL/QifSTWkRZt+hbDf Vt0hTHAHH6VdxJRowAbnxusrHm6AdYtVpBvbwCjcbdxxxHvyLkcza3pIU6tOFpqHQlTd q0GBWwaVhSgaLYL2ZQRcQYDnKNu5qpXNRuZeXFzsBKzB48C/PpZleJYZARIds7x6w4V6 Qx7Na6nNweszhrXTySzdxY1PPHJBmnFLAw9hsLAW6s3YaDeZhDQVu8m/RdvC6ie/93Hh 8spQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765868975; x=1766473775; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6dNPZ/bieSxq1oY8+0BuXs/EOgOdL2p+iOrnlU2Ygm0=; b=kK+dYPlP//aZY8vUnRa5C/qu1jJ1anV5wcOCFYgT0hmUexEQHIXfAL7p8UCG4BHHEA 6hsLb2U9WOT+QLcdFcN0GUncapckW08e8RkA1yo8QXrWTMH5jFysF/qxx+XTJfeslewO 27e0R82LgN2ZRgptlxGrBW8SCdzVzkXo8SAjRZNbWSblq8Vek/ZtORj002RWnOXMKEug gIJE2OH7QnQsdTsiD84hqWeDkoPgD8j7KDw1upnVPJNmm5zKN6Ypnj+umiR6oPwnPdD/ BSKyfdRNrQqzvrt9yhkuZByyfdWcOz4AWbLdZHPd+gwKiStsMBlkNdl9Uww9XRjkIWoI PbzQ== X-Gm-Message-State: AOJu0YxrOnXz639jootFvE5w8wQz4HzFEdWGFTNvkBRUlsrKNf+oWwq3 oa82thqQp/lu/Jf09XXJNfJ6YfgFismLcvG2eFfe+13NyoMfip9R3mGnQICm5gu2AXX6Jk1+uCJ OGTqJMTIvuuZF/NpK5AMXVyjUvpTzdOl4Jw== X-Gm-Gg: AY/fxX4P1oM9vVrgIOWO8eQPh5tbzEWz4Kg4xGw7me9EqDX0yeuPDFDNSiUgU0pm8yT 2x9TdoyyXF9Ld6IS1eByPquNvGBKxwuoUhqRBIllL4fs9chv6SyI3x/WCtL9x+juy+J1VzxaUpf E6akh9SLw4Pw/WdgeOE2QMEIf/UL0rE0y6kAZSx33XwoS6JXUfwzRpGHHxujCYeTgQnefsPRJXM VglRmJPqg8IaVifEvk+bYQ1vcsl9e3P0VM7IN9MTMugmUlLQBBFASmASUKUmxfzEZFx0MgigjWN q82YNqVw4zzkav1kBMajphcv7tWJzJx4A4NsfPA= X-Google-Smtp-Source: AGHT+IF9c8CqqUuig8Yb5qeb8+S1mYRh2u5mDR0YrMT3KkObnhjknLhznabmA9q1NIocAhfzSwBJNBTG81PyvTILY1w= X-Received: by 2002:a05:690c:dd3:b0:786:91ac:e14a with SMTP id 00721157ae682-78e66e6c614mr99160197b3.4.1765868974600; Mon, 15 Dec 2025 23:09:34 -0800 (PST) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: <1BB46A91-C7F4-4F9E-A3A8-24B9DFC3DB3A@gmail.com> In-Reply-To: <1BB46A91-C7F4-4F9E-A3A8-24B9DFC3DB3A@gmail.com> Date: Tue, 16 Dec 2025 04:09:23 -0300 X-Gm-Features: AQt7F2qDENayjvZf0b1K5IOFx-iRMOA39LtwljmuqcG8xbmnRZDF4wp-q3vgwiw Message-ID: Subject: Re: [PHP-DEV] [RFC] Context Managers To: Dmitry Derepko Cc: php internals Content-Type: multipart/alternative; boundary="000000000000f3773e06460c68ea" From: deleugyn@gmail.com (Deleu) --000000000000f3773e06460c68ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 16 Dec 2025 at 02:58 Dmitry Derepko wrote: > > > > On Dec 16, 2025, at 1:19=E2=80=AFAM, Larry Garfield > wrote: > > > > =EF=BB=BFOn Thu, Dec 4, 2025, at 10:46 AM, Larry Garfield wrote: > >>> On Tue, Nov 4, 2025, at 2:13 PM, Larry Garfield wrote: > >>> Arnaud and I would like to present another RFC for consideration: > >>> Context Managers. > >>> > >>> https://wiki.php.net/rfc/context-managers > >>> > >>> You'll probably note that is very similar to the recent proposal from > >>> Tim and Seifeddine. Both proposals grew out of casual discussion > >>> several months ago; I don't believe either team was aware that the > >>> other was also actively working on such a proposal, so we now have tw= o. > >>> C'est la vie. :-) > >>> > >>> Naturally, Arnaud and I feel that our approach is the better one. In > >>> particular, as Arnaud noted in an earlier reply, __destruct() is > >>> unreliable if timing matters. It also does not allow differentiating > >>> between a success or failure exit condition, which for many use cases > >>> is absolutely mandatory (as shown in the examples in the context > >>> manager RFC). > >>> > >>> The Context Manager proposal is a near direct port of Python's > >>> approach, which is generally very well thought-out. However, there a= re > >>> a few open questions as listed in the RFC that we are seeking feedbac= k > >>> on. > >>> > >>> Discuss. :-) > >> > >> More updates to Context Managers: > >> > >> * We have added "masking" for the context variable, using essentially > >> the same technique as the block scope RFC. > >> * We have added support for `try using`, as a shorthand for when you > >> want to wrap a try-catch-finally around a using statement anyway. > >> > >> More details of both are in the RFC. > >> > >> As no one seems to have a strong opinion on `continue`, we will most > >> likely proceed with the current approach of matching `switch` behavior= . > >> > >> There doesn't seem to be much interest in making `using` an expression= , > >> which I find unfortunate, but that means we'll probably drop that. > >> Fortunately it is probably possible to change in the future if the nee= d > >> arises (the way `throw` was changed). > >> > >> --Larry Garfield > > > > Since the only feedback on what to use for "as" was that =3D> makes sen= se, > we have changed the RFC to use =3D> instead. So the new syntax is > > > > using (new CM() =3D> $cVar) { > > // Do stuff here. > > } > > > > --Larry Garfield > > > I=E2=80=99d ask you to get back to =E2=80=9Cuse=E2=80=9D keyword, despite= of it=E2=80=99s in use in > Laravel or somewhere else. > As a developer I cannot even imagine what =E2=80=9Cuse=E2=80=9D could mea= n in web > frameworks context, I hope it could have a better name and at the same ti= me > we can advise to use namespaces if you don=E2=80=99t want to get somethin= g broken > after upgrading language. > Just my 5 cents. > > > -- > Best regards, > Dmitrii Derepko. > @xepozz I have considered asking the same thing in this thread. I have used Laravel everyday for the last decade and I know how Laravel with helper works. The reason I decided not to voice this out is because Larry said that even if Laravel used namespaces it would still not work because the word would be reserved. I=E2=80=99m sure it wouldn=E2=80=99t be the end of the world to refactor bi= llions of lines of code across the industry for a namespace, but for an entire rename of the function I guess we=E2=80=99re between a rock and a hard place anyway. = Plus, I kind of got used to using fairly quickly. > --000000000000f3773e06460c68ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, 16 Dec 2025 at 02:58 Dmitry Derepko <xepozzd@gmail.com> wrote:


> On Dec 16, 2025, at 1:19=E2=80=AFAM, Larry Garfield <larry@garfieldtech.com>= ; wrote:
>
> =EF=BB=BFOn Thu, Dec 4, 2025, at 10:46 AM, Larry Garfield wrote:
>>> On Tue, Nov 4, 2025, at 2:13 PM, Larry Garfield wrote:
>>> Arnaud and I would like to present another RFC for considerati= on:
>>> Context Managers.
>>>
>>> https://wiki.php.net/rfc/context-managers<= br> >>>
>>> You'll probably note that is very similar to the recent pr= oposal from
>>> Tim and Seifeddine.=C2=A0 Both proposals grew out of casual di= scussion
>>> several months ago; I don't believe either team was aware = that the
>>> other was also actively working on such a proposal, so we now = have two.
>>> C'est la vie. :-)
>>>
>>> Naturally, Arnaud and I feel that our approach is the better o= ne.=C2=A0 In
>>> particular, as Arnaud noted in an earlier reply, __destruct() = is
>>> unreliable if timing matters.=C2=A0 It also does not allow dif= ferentiating
>>> between a success or failure exit condition, which for many us= e cases
>>> is absolutely mandatory (as shown in the examples in the conte= xt
>>> manager RFC).
>>>
>>> The Context Manager proposal is a near direct port of Python&#= 39;s
>>> approach, which is generally very well thought-out.=C2=A0 Howe= ver, there are
>>> a few open questions as listed in the RFC that we are seeking = feedback
>>> on.
>>>
>>> Discuss. :-)
>>
>> More updates to Context Managers:
>>
>> * We have added "masking" for the context variable, usin= g essentially
>> the same technique as the block scope RFC.
>> * We have added support for `try using`, as a shorthand for when y= ou
>> want to wrap a try-catch-finally around a using statement anyway.<= br> >>
>> More details of both are in the RFC.
>>
>> As no one seems to have a strong opinion on `continue`, we will mo= st
>> likely proceed with the current approach of matching `switch` beha= vior.
>>
>> There doesn't seem to be much interest in making `using` an ex= pression,
>> which I find unfortunate, but that means we'll probably drop t= hat.=C2=A0
>> Fortunately it is probably possible to change in the future if the= need
>> arises (the way `throw` was changed).
>>
>> --Larry Garfield
>
> Since the only feedback on what to use for "as" was that =3D= > makes sense, we have changed the RFC to use =3D> instead.=C2=A0 So = the new syntax is
>
> using (new CM() =3D> $cVar) {
>=C2=A0 // Do stuff here.
> }
>
> --Larry Garfield


I=E2=80=99d ask you to get back to =E2=80=9Cuse=E2=80=9D keyword, despite o= f it=E2=80=99s in use in Laravel or somewhere else.
As a developer I cannot even imagine what =E2=80=9Cuse=E2=80=9D could mean = in web frameworks context, I hope it could have a better name and at the sa= me time we can advise to use namespaces if you don=E2=80=99t want to get so= mething broken after upgrading language.
Just my 5 cents.


--
Best regards,
Dmitrii Derepko.
@xepozz

I have co= nsidered asking the same thing in this thread. I have used Laravel everyday= for the last decade and I know how Laravel with helper works. The reason I= decided not to voice this out is because Larry said that even if Laravel u= sed namespaces it would still not work because the word would be reserved.<= /div>

I=E2=80=99m sure it woul= dn=E2=80=99t be the end of the world to refactor billions of lines of code = across the industry for a namespace, but for an entire rename of the functi= on I guess we=E2=80=99re between a rock and a hard place anyway. Plus, =C2= =A0I kind of got used to using fairly quickly.
--000000000000f3773e06460c68ea--