Re: function autoloading v4 RFC
| From: | Rob Landers | Date: | Wed, 21 Aug 2024 00:31:27 +0000 |
| Subject: | Re: function autoloading v4 RFC | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-125080@lists.php.net to get a copy of this message | ||
On Mon, Aug 19, 2024, at 20:28, Mel Dafert wrote:
> On August 15, 2024 5:22:51 PM GMT+02:00, Rob Landers <rob@bottled.codes> wrote:
> >Hello internals,
> >
> >I've decided to attempt an RFC for function autoloading. After reading hundreds of
> >ancient (and recent) emails relating to the topic along with several abandoned RFCs from the past,
> >and after much review, I've decided to put forth a variation of a previous RFC, as it seemed
> >the least ambitious and the most likely to work:
> >
> >https://wiki.php.net/rfc/function_autoloading4
> >
> >Please let me know what you think. An implementation should be along before opening it for
> >a vote (now that I realize how important that is).
> >
> >— Rob
>
> Hello,
>
> I've also noted that on another RFC, but I think it applies here too:
> Any new constants that are shaped like an enum and used like an enum should just be
> an actual enum. I think instead of
SPL_AUTOLOAD_CLASS and
> SPL_AUTOLOAD_FUNCTION,
> there should be an enum AutoloadType (to be bikeshed), and the
> new parameters
> should be typed as such, instead of int.
>
> Regards,
> Mel
>
Hey Mel,
I spent a couple of hours trying to do this today. But due to the weird dependency hell that SPL
lives in right now, I'm not sure it can be an enum (or at least, the linker kept messing up my
version of PHP to the point where it couldn't even run—it was bizarre; I've only seen
stuff like that with incompatible cgo shenanigans. I will have to try again later when I next rebase
my branch).
I've reached out to Gina about their RFC and my RFC joining forces. Gina's RFC introduces
an entirely new API for autoloading and neatly side-steps the whole thing.
— Rob