Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108002
MIME-Version: 1.0
References: <DM5PR07MB30672DEC89A0351460769702F9230@DM5PR07MB3067.namprd07.prod.outlook.com>
 <CALKiJKr7d=qKoRAd3xhPQXzMWpQPLoX4QCxU6WyAM+2C5Y0LVg@mail.gmail.com>
 <DM5PR07MB3067CA908C15F6C4EBE2AA3FF9230@DM5PR07MB3067.namprd07.prod.outlook.com>
 <CALKiJKoN5auc6z4Z_67OdOqLhxfgdJBB8=-LG5L_4=T3oijUzw@mail.gmail.com>
 <DM5PR07MB306759CCF5831739C923B28FF9230@DM5PR07MB3067.namprd07.prod.outlook.com>
 <CALKiJKr60h+4Rh=hq3_JvGyKyZfe6VGn7fHjmQpCvEOPZhXigw@mail.gmail.com>
 <DM5PR07MB306725399C3E3F02D61E40D6F93D0@DM5PR07MB3067.namprd07.prod.outlook.com>
 <97a60300-6041-5ce0-e509-91657235650a@gmail.com>
In-Reply-To: <97a60300-6041-5ce0-e509-91657235650a@gmail.com>
Date: Mon, 6 Jan 2020 10:07:15 +0100
Message-ID: <CADqTB_j-69dFv-Qw2=WabHsFXj-YzGRnrycN6L9T9FHaJRfncQ@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c209a0059b74fc32"
Subject: Re: [PHP-DEV] Autoloading functions/consts without a performance impact
From: rasmus@mindplay.dk (Rasmus Schultz)

--000000000000c209a0059b74fc32
Content-Type: text/plain; charset="UTF-8"

On Sun, Jan 5, 2020 at 7:48 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> On 05/01/2020 18:03, tyson andre wrote:
> >> Yes, I'm saying that the autoloader should be called for each lookup, so
> >> autoloading of Foo\strlen should come between checking if Foo\strlen is
> >> defined, and checking if \strlen is defined.
> > That would be the intuitive approach for a language,
> > but as mentioned earlier,
> > it would significantly harm performance of existing code for php 7
> > (slightly without an autoloader, more with autoloaders),
> > and I can't imagine that getting approved.
>
>
> Yes, I'm fully aware of the downsides. I just think relaxing that
> constraint would lead to a horribly confusing language.
>
>
> > I'd considered that option, but that introduces its own surprises,
> > which I'd consider to have more frequent and significant impact on
> applications that start using this.
> >
> > namespace NS;
> > function f1($x) {
> >       return mb_strlen($x) + 1;
> > }
> > function f2($x) {
> >       return \mb_strlen($x) * 2;
> > }
> >
> > Calling f2() then f1() would work, but f1() then f2() would not work,
> because f1() wouldn't autoload.
>
>
> True; again, it violates the user's expectation, which I think can be
> summed up this way:
>
> - The autoloader for a function should run the first time that function
> would run if it was pre-defined.
>
> That in turn stems from an even more fundamental expectation:
>
> - An application using an autoloader should behave the same as one which
> defines all functions in advance.
>
>
> The more I think about it, the more I think we should just be optimising
> for the case where everything *is* defined in advance. As far as I know,
> PHP's autoloading is an anomaly among programming languages, and maybe
> it has outlived its usefulness.
>

I would argue that name resolution, the way it works right now, is also
somewhat of an anomaly among programming languages.

Removing autoloading from the language would have two major implications:

1. You have to figure out what to load in advance - thinking you can just
preload all *.php files in a folder is probably pretty naive, because some
of those files (PHP being a scripting language) are going to be actual be
scripts (CLI scripts, tests, etc.) and not just declarations.

2. Code generation - and I mean, think of that what you want, but PHP lends
itself well to code generation, and many projects (ORMs, template engines,
annotation parsers, AOP and other meta-programming frameworks, etc.) use
the autoloader as a hook to generate code on the fly.

So this seems like a fairly drastic change to the language, which might
render a lot of projects defunct with no recourse.

--000000000000c209a0059b74fc32--