Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125444 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 D9DF11A00BD for ; Thu, 5 Sep 2024 20:45:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1725569264; bh=oVQKhH2249dNuTflcG93S2TOOhCsvNm3rDmmfyqFhps=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=Ys+Wg1HvbzLbqYuuvqQJdkRh3l17UgLkefDHc4pMTNTsJhDVC/pPCqUMlzcc29gur 3s3fQGGOk4Jcq16HBh7/2VP7TvMviKSu0XoTcCpuvIlXjqmxN3/P1upNvfsxZ0nJ/y LCgM5O4WlpVsC+YAlogFGvZy21cOKQtGNUMaHHXrFXHou89e5xKKMc1KxTHzprV/Ow IctDotyDaif5F1jIg919Wq0nGwYKUnSUdIkiAROpNahYKHgweGjIRIR/YAzyRNeUaC hcmg2/czaYgDeGz2mPAMdl5Zzid8vKyY/I6hccnE4pX6c8GE2BfDNa2Mt8+vckxbxq RCiDCDtmamrEg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id DD5CF180054 for ; Thu, 5 Sep 2024 20:47:42 +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_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS, SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from fout8-smtp.messagingengine.com (fout8-smtp.messagingengine.com [103.168.172.151]) (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 ; Thu, 5 Sep 2024 20:47:42 +0000 (UTC) Received: from phl-compute-03.internal (phl-compute-03.phl.internal [10.202.2.43]) by mailfout.phl.internal (Postfix) with ESMTP id 55F88138037E; Thu, 5 Sep 2024 16:45:43 -0400 (EDT) Received: from phl-imap-09 ([10.202.2.99]) by phl-compute-03.internal (MEProxy); Thu, 05 Sep 2024 16:45:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm2; t=1725569143; x= 1725655543; bh=oVQKhH2249dNuTflcG93S2TOOhCsvNm3rDmmfyqFhps=; b=v pjNyB4U5RC/oT2iR2foeuqHxanW/k6qTvi7dYHUrFqDaw6SBHoi3yP/WeOXOC7m/ OwGZHQ2p5AuajinbztVG9ulucKJ0LellHLyxLsMJcwLV1KMR9yOLoZS0i8GdtGaP 1D0HnDfOq/UsOK/WAj9+4iJZTVZyBkvw1AdhIV5D+FybfEKEdooPhjO7dMs7awik ayCnt60QQdI0qWvtn0pR18dj1AKbTFzabDLWCe9OFDX7x7Qh08h99TX90DEBoORB Ei5GVoEjP5V9MV1K03zcw9eRBQ0TJn0nGTCEiSsRv45qS5iumCHbTSRE+lReOq6R 2KzGllZrKXAgP1uVRFIEg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1725569143; x=1725655543; bh=oVQKhH2249dNuTflcG93S2TOOhCs vNm3rDmmfyqFhps=; b=efELO1w7vf+Ev1v/iO3szkTbPXSwZOpnStLUWH8y4a3c hQbfXzDG4a8d1YmttvX8j64NRHRggqDqq66ugI/IBW8PV6z06Rqm/SrrFgs3ouku KD8ff6aPcPBeSPR5J/jG/G5Wum31cBvni/tqA4piqh5Qv/CWAlLUaBkA04A5hAbs Qt3sbK+N8BC9ng/fwenY1gkosOSyo5TssQXAyJFbWHsu5MrVgsUKw1yrQzICqu7/ 8Rs9OT+cbRrQojeJn0kJcF37aOvADPSlXFyddVikkqdQyrksyo9gVvIm5nPdPJZb C8W9wlFSxJSLyxiNjYzJJwNWLBA+JipvcqNtgJ7Npw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudehledgudehvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefoggffhffvvefkjghfufgtsegrtderreertdej necuhfhrohhmpedftfhosgcunfgrnhguvghrshdfuceorhhosgessghothhtlhgvugdrtg houggvsheqnecuggftrfgrthhtvghrnhepieeuteehvddvfeejhffgieehleehhedthfef keejffelgfevvdekudetjeejtddtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomheprhhosgessghothhtlhgvugdrtghouggvshdpnhgspghrtghp thhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhgrkhhosgesghhivh honhhirdgukhdprhgtphhtthhopehinhhtvghrnhgrlhhssehlihhsthhsrdhphhhprdhn vght X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id D2B0C780067; Thu, 5 Sep 2024 16:45:42 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 Date: Thu, 05 Sep 2024 22:45:22 +0200 To: "Jakob Givoni" Cc: internals@lists.php.net Message-ID: <3b70839a-6199-4186-9dbb-7e006ba7411b@app.fastmail.com> In-Reply-To: References: <2716f729-4008-4f75-8412-861d8960b746@app.fastmail.com> <4f404d71-6581-44d6-8a87-dc6c605e0a60@app.fastmail.com> Subject: Re: [PHP-DEV] function autoloading v4 RFC Content-Type: multipart/alternative; boundary=9505bc49f2184d8c878997751d71fb45 From: rob@bottled.codes ("Rob Landers") --9505bc49f2184d8c878997751d71fb45 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Sep 5, 2024, at 21:03, Jakob Givoni wrote: >=20 >=20 > On Wed, Sep 4, 2024 at 9:18=E2=80=AFPM Rob Landers = wrote: >> __ >> On Wed, Sep 4, 2024, at 17:16, Jakob Givoni wrote: >>> =20 >>>> 2. I've removed artificial restrictions on the constants in which a= ll functions that take them can accept both at the same time and behave = appropriately. >>>=20 >>> I'm not a big fan passing flags and using binary operations to combi= ne options into a single parameter.=20 >>> 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 w= ith 3 cases, FUNCTION, CLASS or BOTH?=20 >>=20 >> Thank you for your opinion, but for cases like this, enums is probabl= y 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 an= d 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 depen= dency 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. >=20 > 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 autolo= ading stream wrappers and constants? Is that something there's a need/de= sire for? >=20 > In any case, it seems less than ideal to introduce a change to existin= g functions now only to change them again after Gina's RFC.=20 >=20 > Which 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 late= r. >=20 > I also mentioned named parameters as an alternative, any thoughts on t= hat? > F.ex. changing one of your examples to: >=20 > 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 = coming from regarding enums and named parameters as a more modern approa= ch, and I appreciate your suggestion to consider them. For the current RFC, I leaned towards using binary flags because they pr= ovide a level of consistency with existing PHP functions. There are also= some technical challenges with using enums here, especially since enums= seem incompatible with SPL due to its recursive dependency. This is som= ething I hope we can address in the future, potentially through Gina's R= FC. I think named parameters could be a good middle ground and might make th= e function calls clearer. If you don't mind me asking, what do you have = against binary flags? 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= 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 long time. 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 wa= nt to risk withdrawing my RFC and Gina's not passing for unrelated reaso= ns; I hope that makes sense. =E2=80=94 Rob --9505bc49f2184d8c878997751d71fb45 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
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:
 
2. I've removed artificial restrictions on the c= onstants in which all functions that take them can accept both at the sa= me time and behave appropriately.

I'= m not a big fan passing flags and using binary operations to combin= e 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 going 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 one of = the worst choices IMHO. As mentioned towards the end of the RFC, I'd lik= e to add further support for other things, such as constants and 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 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.
<= /div>

I see that under "Future sco= pe" 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 wrapper= s and constants? Is that something there's a need/desire for?
<= div>
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 sure what you have against their u= se 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); // C= alls both autoloaders with the name 'func'

Hey Jakob,

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

For the current RFC, I leaned towards using binary flags because t= hey provide a level of consistency with existing PHP functions. There ar= e also 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 Gi= na'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?

I also understand your concern about making adjustment= s to the API twice and how it might have to change again if Gina's RFC p= asses. My thinking was 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.

I'm not oppo= sed to holding off on merging the implementation if it makes sense to wa= it and see how Gina's proposal develops, but I also don't want to risk w= ithdrawing my RFC and Gina's not passing for unrelated reasons; I hope t= hat makes sense.

=E2=80=94 Rob


--9505bc49f2184d8c878997751d71fb45--