Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125441
Precedence: bulk
MIME-Version: 1.0
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>
In-Reply-To: <4f404d71-6581-44d6-8a87-dc6c605e0a60@app.fastmail.com>
Date: Thu, 5 Sep 2024 21:03:34 +0200
Message-ID: <CAJmjfvVfhTqNkaOdYqNNupZsRPF5G2RSj6AANUBdXtPK2caAQg@mail.gmail.com>
Subject: Re: [PHP-DEV] function autoloading v4 RFC
To: Rob Landers <rob@bottled.codes>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000359807062163f3f8"
From: jakob@givoni.dk (Jakob Givoni)

--000000000000359807062163f3f8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 4, 2024 at 9:18=E2=80=AFPM Rob Landers <rob@bottled.codes> wrot=
e:

> 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 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 to:

spl_autoload_call('func', function: true, class: true); // Calls both
autoloaders with the name 'func'

Best,
Jakob

--000000000000359807062163f3f8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Sep 4, 2024 at 9:18=E2=80=AFP=
M Rob Landers &lt;rob@bottled.codes&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div class=3D"msg-6769992881184812630"><u>=
</u><div><div>On Wed, Sep 4, 2024, at 17:16, Jakob Givoni wrote:</div><bloc=
kquote type=3D"cite" id=3D"m_-6769992881184812630qt"><div dir=3D"ltr"><div>=
<div>=C2=A0<br></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">2. I&#39;ve removed artifi=
cial restrictions on the constants in which all functions that take them ca=
n accept both at the same time and behave appropriately.<br></blockquote><d=
iv><br></div><div>I&#39;m not a big fan passing flags and using binary oper=
ations to=C2=A0combine options into a single parameter.=C2=A0<br></div><div=
>It works, but it&#39;s opaque and old-school.<br></div><div>We have both n=
amed parameters and enums now, can&#39;t we just use those going forward, m=
aking each option a separate parameter or using enums with 3 cases,=C2=A0FU=
NCTION, CLASS or BOTH?=C2=A0<br></div></div></div></blockquote><div><br></d=
iv><div>Thank you for your opinion, but for cases like this, enums is proba=
bly one of the worst choices IMHO. As mentioned towards the end of the RFC,=
 I&#39;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&#39;t get it to link) due to SPL having a recursive depende=
ncy on itself. This is what Gina&#39;s RFC seeks to rectify by breaking aut=
oloading out of SPL. This RFC focuses purely on function autoloading.</div>=
</div></div></blockquote><div><br></div><div>I see that under &quot;Future =
scope&quot; you put:</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
>Potentially, constants and stream wrappers can be added in a similar fashi=
on.</blockquote><div>Trying to figure out if you are referring to the possi=
bility of=C2=A0autoloading stream wrappers and constants? Is that something=
 there&#39;s a need/desire for?</div><div><br></div><div>In any case, it se=
ems less than ideal to introduce a change to existing functions now only to=
 change them again after Gina&#39;s RFC.=C2=A0</div><div>Which means we&#39=
;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.</div><div><br></div=
><div>I also mentioned named parameters as an alternative, any thoughts on =
that?</div><div>F.ex. changing one of your examples to:</div><div><br></div=
><div>spl_autoload_call(&#39;func&#39;, function: true, class: true); // Ca=
lls both autoloaders with the name &#39;func&#39;<br></div><div><br></div><=
div>Best,</div><div>Jakob</div><div><br></div></div></div>

--000000000000359807062163f3f8--