On Mon, Aug 8, 2016 at 12:51 PM, Rowan Collins <rowan.coll...@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, rather >> than a backfill. >> >> We only support autoloading for unambiguous names — 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 in > 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 namespace: > > 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()" would > 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 do > 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 functions > 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
