Re: [RFC] New core autoloading mechanism with support for function autoloading
| From: | Dan Ackroyd | Date: | Sun, 16 Apr 2023 16:22:01 +0000 |
| Subject: | Re: [RFC] New core autoloading mechanism with support for function autoloading | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-120045@lists.php.net to get a copy of this message | ||
On Thu, 13 Apr 2023 at 11:39, Jordi Boggiano <j.boggiano@seld.be> wrote:
>
> On 2023-04-12 22:26, Rowan Tommins wrote:
> > I could just about live with that example changing so that the
> > fallback was cached, but I definitely don't think an explicit call
> > like \foo\strlen('x') should become an implicit alias for
> > \strlen('x'), which is apparently the current proposal.
> >
> > I really like the majority of this proposal, but right now would vote
> > against it based on that.
> >
> I agree here, I missed that fact while reviewing the RFC as I just
> understood it as an internal cache that \foo\strlen => \strlen, but
> function_exists('foo\strlen') should still return false IMO until it is
> defined, and once it is defined the cache should be busted.
Thanks for the code example. Code is a great of being clear...
particularly when I've gotten the wrong end of the stick.
Yeah, that would be a BC break.
For now, I'll update the RFC words to say that, but that means we need
to go and do some thinking, to figure out how to proceed.
cheers
Dan
Ack