Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125449 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 qa.php.net (Postfix) with ESMTPS id 4194B1A00BD for ; Fri, 6 Sep 2024 11:40:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1725622964; bh=E2w2szUMCyK6aLgafBk6UqCtS13S1RIBCdSQajoTCTg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=VIn8QYs9Otkx5KRyb/E0przU21JJdYVNvfO9zvAAUBB+aRYIz6jXNX+rmauwDa5FE iFCvL5LolVeKru/FqI5Q5nyR8LHz4D4HOebXPdE8FOO77wH5dVMyS4t6+DN1ns4iIt LUY/1X50WC3ORCayct6mjzVO3rhyv0m1QIseeloYNANGcqHyk9qzQZZfi22eTnFvy5 gZaD/bxAthJqM/S6kPyY0yZO0qDxdl0hmum2g3nF9v5SOGMSsX5FfSGmoS2SP2iTQ5 oiAww6NcUxsJB+ZloBJKAHSLdsFdzJQV8AXQHWv/ymwZtVo67rtsLiyKtR5RofBGhU wm6vQxN7o1SXg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 24084180068 for ; Fri, 6 Sep 2024 11:42:43 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from smtp-out3.simply.com (smtp-out3.simply.com [94.231.106.210]) (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 ; Fri, 6 Sep 2024 11:42:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.simply.com (Simply.com) with ESMTP id 4X0Z6d2g31z1DPjw for ; Fri, 6 Sep 2024 13:40:41 +0200 (CEST) Received: from mail-yw1-f181.google.com (mail-yw1-f181.google.com [209.85.128.181]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by smtp.simply.com (Simply.com) with ESMTPSA id 4X0Z6d07Sdz1DPkg for ; Fri, 6 Sep 2024 13:40:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=givoni.dk; s=unoeuro; t=1725622841; bh=fb7IuvyUZBok9y/vqwWeoKVF7M0MMUiRdzfQGI6b1Iw=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=h/y1i6zyCZKu0A4swFgVKR/By6D7pwyunMJyYBD/9Kw0viA/NQl9Q2F2Y7DHQR7k/ 9KxYHeF9psKEByWUoAECBUbwyq/T56XOg/FIJfCZ7zV9TIlIN4x5so9nr39ZPVYxzq dboei5vUtlc8GltxBILhIIWnmKaOqhlW6qJS51CY= Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-6cdae28014dso14147657b3.1 for ; Fri, 06 Sep 2024 04:40:40 -0700 (PDT) X-Gm-Message-State: AOJu0YyVII4+IdkM3qkqsfnb9+wtLMz10mCRCIFn8/DbuRkBObdmHutc ATyCYgmpU0CcYa52Ail3RX5NkoY13vvVAenO7qkKXxz9iegCP6tDYXKDuGOsDkQdoRRfdvKgAOd Up29e3rLoBWOWsHo4oyuEI+jiHUs= X-Google-Smtp-Source: AGHT+IGpxeaeSjB6Nxn0rd050CMB6BXkF2/3Fe6PTmZF3Vbvs6ZU/nPys60rRGYacR+YH9qYINZIVpA52u6lF2pXsiM= X-Received: by 2002:a05:690c:2c84:b0:63b:ba95:c8b3 with SMTP id 00721157ae682-6db442ba0cfmr15842787b3.6.1725622839806; Fri, 06 Sep 2024 04:40:39 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <2716f729-4008-4f75-8412-861d8960b746@app.fastmail.com> <4f404d71-6581-44d6-8a87-dc6c605e0a60@app.fastmail.com> <3b70839a-6199-4186-9dbb-7e006ba7411b@app.fastmail.com> In-Reply-To: <3b70839a-6199-4186-9dbb-7e006ba7411b@app.fastmail.com> Date: Fri, 6 Sep 2024 13:40:28 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PHP-DEV] function autoloading v4 RFC To: Rob Landers Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="0000000000006219b2062171e00c" From: jakob@givoni.dk (Jakob Givoni) --0000000000006219b2062171e00c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rob, On Thu, Sep 5, 2024 at 10:45=E2=80=AFPM Rob Landers wro= te: > On Thu, Sep 5, 2024, at 21:03, Jakob Givoni wrote: > > > > On Wed, Sep 4, 2024 at 9:18=E2=80=AFPM Rob Landers wr= ote: > > > On Wed, Sep 4, 2024, at 17:16, Jakob Givoni wrote: > > > > 2. I've removed artificial restrictions on the constants in which all > functions that take them can accept both at the same time and behave > appropriately. > > > I'm not a big fan passing flags and using binary operations to combine > options into a single parameter. > It works, but it's opaque and old-school. > We have both named parameters and enums now, can't we just use those goin= g > forward, making each option a separate parameter or using enums with 3 > cases, FUNCTION, CLASS or BOTH? > > > Thank you for your opinion, but for cases like this, enums is probably on= e > of the worst choices IMHO. As mentioned towards the end of the RFC, I'd > like to add further support for other things, such as constants and strea= m > filters. Further, it appears that enums cannot be used in SPL (at least, = I > couldn't get it to link) due to SPL having a recursive dependency on > itself. This is what Gina's RFC seeks to rectify by breaking autoloading > out of SPL. This RFC focuses purely on function autoloading. > > > I see that under "Future scope" you put: > > Potentially, constants and stream wrappers can be added in a similar > fashion. > > Trying to figure out if you are referring to the possibility > of autoloading stream wrappers and constants? Is that something there's a > need/desire for? > > In any case, it seems less than ideal to introduce a change to existing > functions now only to change them again after Gina's RFC. > > Which means we'll be locked into binary flags even if enums (not even sur= e > what you have against their use in this case) will be possible later. > > I also mentioned named parameters as an alternative, any thoughts on that= ? > F.ex. changing one of your examples to: > > spl_autoload_call('func', function: true, class: true); // Calls both > autoloaders with the name 'func' > > > Hey Jakob, > > Thank you for sharing your thoughts on this. I see where you=E2=80=99re c= oming > from regarding enums and named parameters as a more modern approach, and = I > appreciate your suggestion to consider them. > > For the current RFC, I leaned towards using binary flags because they > provide a level of consistency with existing PHP functions. There are als= o > some technical challenges with using enums here, especially since enums > seem incompatible with SPL due to its recursive dependency. This is > something I hope we can address in the future, potentially through Gina's > RFC. > > I think named parameters could be a good middle ground and might make the > function calls clearer. If you don't mind me asking, what do you have > against binary flags? > Sure! I've always just intuitively disliked them, but here's an attempt at rationalizing my distaste: - It's not intuitive and easy to remember. If you are a casual user of functions accepting bitmasks, you may remember that you can pass several flags, but what is the syntax again? Say I want to pass FLAG_1 AND FLAG_2, so I use the AND operator, right? That would be the most intuitive answer... But no, it's OR - and how do we write OR in php? Using double pipe ||, right? Ah, no for bitwise operations it's a single pipe |. Not to mention that sometimes you need to use the exclusive or the not operator to achieve your goal. The error_reporting function is another famous example that needs its own bitmask calculator page! It's not a great user experience and can easily lead to subtle bugs... - There's no standard way to document them. F.ex. see the documentation for json_encode. The function API just says it's an integer. You have to look further to understand that it's actually a "bitmask" - which is not a native type in PHP. And you have to go to another page about bitwise operators to understand how to compose the flags. Your IDE will most probably not help you the least, the way it would if it was an enum or a named boolean parameter. - Using a bitmask parameter seems "lazy" on part of the implementer (no offense intended!), putting all the work of understanding the flags and how to compose them on the end-user. That being said, if the PHP community is generally enthusiastic about bitmasks, it's not a deal breaker for me :-) > > I also understand your concern about making adjustments to the API twice > and how it might have to change again if Gina's RFC passes. My thinking w= as > that by moving forward with this proposal, we at least make some progress > on function autoloading, which has been debated, off-and-on, for a long > time. > Function autoloading is much needed, thank you for working on this! > > I'm not opposed to holding off on merging the implementation if it makes > sense to wait and see how Gina's proposal develops, but I also don't want > to risk withdrawing my RFC and Gina's not passing for unrelated reasons; = I > hope that makes sense. > Your proposed PHP version is 8.5 or later, maybe there's still time to see how it unfolds? > > =E2=80=94 Rob > > > --0000000000006219b2062171e00c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rob,

On Thu, Sep 5, 2024 at 10:45=E2=80=AFPM Rob L= anders <rob@bottled.codes> wrote:
<= div>On Thu, Sep 5, 2024, at 21:03, Jakob Givoni wrote:


On Wed, Sep 4, 2024 at = 9:18=E2=80=AFPM Rob Landers <rob@bottled.codes> wrote:

On Wed, Sep 4, = 2024, at 17:16, Jakob Givoni wrote:
=C2=A0
2. I've removed artif= icial restrictions on the constants in which all functions that take them c= an accept both at the same time and behave appropriately.
<= div>
I'm not a big fan passing flags and using binary ope= rations to=C2=A0combine options into a single parameter.=C2=A0
It works, but it's opaque and old-school.
We have both = named parameters and enums now, can't we just use those going forward, = making each option a separate parameter or using enums with 3 cases,=C2=A0F= UNCTION, CLASS or BOTH?=C2=A0

Thank you for your opinion, but for cases like this, enums is prob= ably one of the worst choices IMHO. As mentioned towards the end of the RFC= , I'd like to add further support for other things, such as constants a= nd stream filters. Further, it appears that enums cannot be used in SPL (at= least, I couldn't get it to link) due to SPL having a recursive depend= ency on itself. This is what Gina's RFC seeks to rectify by breaking au= toloading out of SPL. This RFC focuses purely on function autoloading.
<= /div>

I see that under "Fu= ture scope" you put:
Potentially,= constants and stream wrappers can be added in a similar fashion.
Trying to figure out if you are referring to the possibility of= =C2=A0autoloading stream wrappers and constants? Is that something there= 9;s a need/desire for?

In any case, it seems l= ess than ideal to introduce a change to existing functions now only to chan= ge them again after Gina's RFC.=C2=A0

Whic= h means we'll be locked into binary flags even if enums (not even sure = what you have against their use in this case) will be possible later.

I also mentioned named parameters as an alternative= , any thoughts on that?
F.ex. changing one of your examples t= o:

spl_autoload_call('func', function:= true, class: true); // Calls both autoloaders with the name 'func'=

Hey Jakob,

Thank you for sharing your thoughts on this. I see whe= re you=E2=80=99re coming from regarding enums and named parameters as a mor= e modern approach, and I appreciate your suggestion to consider them.

For the current RFC, I leaned towards using binary = flags because they provide a level of consistency with existing PHP functio= ns. There are also some technical challenges with using enums here, especia= lly since enums seem incompatible with SPL due to its recursive dependency.= This is something I hope we can address in the future, potentially through= Gina's RFC.

I think named parameters coul= d be a good middle ground and might make the function calls clearer. If you= don't mind me asking, what do you have against binary flags?
=

Sure! I've always ju= st intuitively disliked them, but here's an attempt at rationalizing my= distaste:
- It's not intuitive and easy to remember. If you = are a casual user of functions accepting bitmasks, you may remember that yo= u can pass several flags, but what is the syntax again? Say I want to pass = FLAG_1 AND FLAG_2, so I use the AND operator, right? That would be the most= intuitive answer... But no, it's OR - and how do we write OR in php? U= sing double pipe ||, right? Ah, no for bitwise operations it's a single= pipe |. Not to mention that sometimes you need to use the exclusive or the= not operator to achieve your goal. The error_reporting function is another= famous example that needs its own bitmask calculator page!=C2=A0 It's = not a great user experience and can easily lead to subtle bugs...
- There's no standard way to document them. F.ex. see the documentatio= n for json_encode. The function API just says it's an integer. You have= to look further to understand that it's actually a "bitmask"= - which is not a native type in PHP. And you have to go to another page ab= out bitwise operators to understand how to compose the flags. Your IDE will= most probably not help you the least, the way it would if it was an enum o= r a named=C2=A0boolean parameter.
- Using a bitmask parameter see= ms "lazy" on part of the implementer (no offense intended!), putt= ing all the work of understanding the flags and how to compose them on the = end-user.

That being said, if the PHP community is= generally enthusiastic about bitmasks, it's not a deal breaker for me = :-)
=C2=A0

=
I also understand your concern about making adjustments to the API twi= ce and how it might have to change again if Gina's RFC passes. My think= ing was that by moving forward with this proposal, we at least make some pr= ogress on function autoloading, which has been debated, off-and-on, for a l= ong time.

Funct= ion autoloading is much needed, thank you for working on this!
= =C2=A0

I'm n= ot opposed to holding off on merging the implementation if it makes sense t= o wait and see how Gina's proposal develops, but I also don't want = to risk withdrawing my RFC and Gina's not passing for unrelated reasons= ; I hope that makes sense.
Your proposed PHP version is=C2=A08.5 or later, maybe there'= ;s still time to see how it unfolds?
=C2=A0

=E2=80=94 Rob


--0000000000006219b2062171e00c--