Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125445
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 05 Sep 2024 22:58:14 +0200
To: "Jakob Givoni" <jakob@givoni.dk>
Cc: internals@lists.php.net
Message-ID: <ec2265f5-64e1-404f-a724-c6fb0633f781@app.fastmail.com>
In-Reply-To: 
 <CAJmjfvVfhTqNkaOdYqNNupZsRPF5G2RSj6AANUBdXtPK2caAQg@mail.gmail.com>
References: <2716f729-4008-4f75-8412-861d8960b746@app.fastmail.com>
 <df217c26-cb23-46d6-b931-431c8971599c@app.fastmail.com>
 <CAJmjfvX4baKOA=MgM8FntPavtnTC+dh+bbfncfP8f1OwiGQDzA@mail.gmail.com>
 <4f404d71-6581-44d6-8a87-dc6c605e0a60@app.fastmail.com>
 <CAJmjfvVfhTqNkaOdYqNNupZsRPF5G2RSj6AANUBdXtPK2caAQg@mail.gmail.com>
Subject: Re: [PHP-DEV] function autoloading v4 RFC
Content-Type: multipart/alternative;
 boundary=8c4240e9a7c143e380441bdddb3e4abe
From: rob@bottled.codes ("Rob Landers")

--8c4240e9a7c143e380441bdddb3e4abe
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 <rob@bottled.codes>=
 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?

Hey Jakob,

I'm replying this in a separate thread because it is more or less 'meta'=
 than my other reply. There have been discussions about this off-and-on =
for awhile, but the gist is that there are people that would find it use=
ful. For example, in my experimental "time" library there is a SECOND an=
d MINUTE constant that must be required if you have the library, even if=
 your code execution path never uses them. So, I think there might be so=
me usefulness to constant autoloading. Further, there are some great asy=
nc libraries that use stream wrappers to hijack/use file_get_contents an=
d friends in an async way, so having autoloading there may also be usefu=
l.

That being said, I wanted to constrain the scope initially as this appea=
red to be a hot topic (autoloading functions) every time it came up. Thu=
s I was preparing myself for a long and drawn-out discussion and kept th=
e scope minimal.

I hope that helps explain why it is under future scope.

=E2=80=94 Rob
--8c4240e9a7c143e380441bdddb3e4abe
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Thu, Sep 5, =
2024, at 21:03, Jakob Givoni wrote:<br></div><blockquote type=3D"cite" i=
d=3D"qt" style=3D""><div dir=3D"ltr"><div dir=3D"ltr"><br></div><div><br=
></div><div class=3D"qt-gmail_quote"><div dir=3D"ltr" class=3D"qt-gmail_=
attr">On Wed, Sep 4, 2024 at 9:18=E2=80=AFPM Rob Landers &lt;rob@bottled=
.codes&gt; wrote:<br></div><blockquote class=3D"qt-gmail_quote" style=3D=
"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;bor=
der-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 20=
4, 204);padding-left:1ex;"><div class=3D"qt-msg-6769992881184812630"><di=
v><u></u><br></div><div><div>On Wed, Sep 4, 2024, at 17:16, Jakob Givoni=
 wrote:<br></div><blockquote type=3D"cite" id=3D"qt-m_-67699928811848126=
30qt"><div dir=3D"ltr"><div><div>&nbsp;<br></div><blockquote style=3D"ma=
rgin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border=
-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, =
204);padding-left:1ex;">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.<br></blockquote><div><br></div><div>I'=
m not a big fan passing flags and using binary operations to&nbsp;combin=
e options into a single parameter.&nbsp;<br></div><div>It works, but it'=
s opaque and old-school.<br></div><div>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,&nbsp;FUNCTION, CLASS or =
BOTH?&nbsp;<br></div></div></div></blockquote><div><br></div><div>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.<br></div><=
/div></div></blockquote><div><br></div><div>I see that under "Future sco=
pe" you put:<br></div><blockquote class=3D"qt-gmail_quote" style=3D"marg=
in-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 20=
4);padding-left:1ex;">Potentially, constants and stream wrappers can be =
added in a similar fashion.<br></blockquote><div>Trying to figure out if=
 you are referring to the possibility of&nbsp;autoloading stream wrapper=
s and constants? Is that something there's a need/desire for?<br></div><=
/div></div></blockquote><div><br></div><div>Hey Jakob,<br></div><div><br=
></div><div>I'm replying this in a separate thread because it is more or=
 less 'meta' than my other reply. There have been discussions about this=
 off-and-on for awhile, but the gist is that there are people that would=
 find it useful. For example, in my experimental "time" library there is=
 a SECOND and MINUTE constant that must be required if you have the libr=
ary, even if your code execution path never uses them. So, I think there=
 might be some usefulness to constant autoloading. Further, there are so=
me great async libraries that use stream wrappers to hijack/use file_get=
_contents and friends in an async way, so having autoloading there may a=
lso be useful.<br></div><div><br></div><div>That being said, I wanted to=
 constrain the scope initially as this appeared to be a hot topic (autol=
oading functions) every time it came up. Thus I was preparing myself for=
 a long and drawn-out discussion and kept the scope minimal.<br></div><d=
iv><br></div><div>I hope that helps explain why it is under future scope=
.</div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></=
body></html>
--8c4240e9a7c143e380441bdddb3e4abe--