Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94919
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <6600076c-d046-bdca-f339-79894781a996@gmail.com>
References: <CADqTB_gBFM_2yNDQemPs68Fab4Hbd8pGj38a3-HSQ+CRcnDyvA@mail.gmail.com>
 <CAF+90c9td1bt2zCbGfXdbGtFO-4qhJuJnkAEdsQDaH+wATDOmA@mail.gmail.com>
 <CADqTB_i9upaFv7MvwjedRL4QYV=b8Y6RCb6bYsawZVxtooxDeQ@mail.gmail.com>
 <CAEsg9X1F_ZnysnnhRhtyedy+0F_fudXS+buU7indKeTKKbc1sw@mail.gmail.com>
 <CANaX5ncBfr+VbBgJKVpWST3kwnzjnEsi2rtBsLi5HG2rU0Q5-g@mail.gmail.com> <6600076c-d046-bdca-f339-79894781a996@gmail.com>
Date: Mon, 8 Aug 2016 14:15:25 +0200
Message-ID: <CAF+90c-cCCCEu9fYjSwV5H7a=od2mNF6bPoGwq_pJ_Pon_WpAA@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114909d60d988405398e5f66
Subject: Re: [PHP-DEV] Function auto-loading
From: nikita.ppv@gmail.com (Nikita Popov)

--001a114909d60d988405398e5f66
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 8, 2016 at 12:51 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> On 07/08/2016 23:42, Davey Shafik wrote:
>
>> Perhaps the solution is to look at this as a forward-only feature, rathe=
r
>> than a backfill.
>>
>> We only support autoloading for unambiguous names =E2=80=94 if you want =
the
>> autoloader to be called, either
>> import the function with use, or use a [fully] qualified name.
>>
>> This should remove the ambiguities and performance concerns.
>>
>
> I actually quite like this suggestion, because it fits with the use case =
I
> see as being most common: replacing static-only classes with a namespace =
of
> related functions. (Remember that "static classes" were rejected at RFC i=
n
> favour of exactly this.)
>
>
> To be clear, the case we'd be "refusing" to autoload (other than global
> functions themselves) would be a function in the *exact* current namespac=
e:
>
> namespace Acme\Foo\Bar;
> do_something(); // won't autoload
>
> But that only matters if namespace "\Acme\Foo\Bar" is split over multiple
> files. In this case, the declaration of "Acme\Foo\Bar\do_something()" wou=
ld
> probably be in the same file anyway, so not need autoloading.
>
>
> Given that we have hierarchical namespaces, this seems a more likely
> scenario:
>
> namespace Acme\Foo\Bar;
> // function autoload for 'Acme\Foo\Bar\Utilities\do_something'
> Utilities\do_something();
>
> Or importing as an alias:
>
> namespace Acme\Foo\Bar;
> use Acme\Stuff\Utilities as Util;
> // function autoload for 'Acme\Stuff\Utilities\do_something'
> Util\do_something();
>
>
> Note that an unqualified function call "do_something()" already doesn't
> look in any imported namespaces, so "use Acme\Stuff\Utilities;" doesn't d=
o
> anything to function name resolution.
>
> So we would be defining a simple rule: "the function autoloader will be
> called at run time for any namespace-qualified function name which is not
> already defined".
>
>
> This feels like a better compromise than an autoload cache, because I can
> see the invalidation rules getting messy, and heavily-used global functio=
ns
> still firing the autoloader for many different possible prefixes.
>

I like this idea as well. In a previous thread I suggested to delay the
autoloader call for unqualified function calls until after the check for an
existing global function. But just not calling the autoloader at all for
unqualified calls is the better solution, as it removes one pretty
arbitrary factor (does this global function exist?) from the autoloader
behavior.

Nikita

--001a114909d60d988405398e5f66--