Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94537
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.41 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <CAF+90c8E_eO1xWLHexNxTFEvFu6DhNyvanTjsGxZ5Ge8aCK0KA@mail.gmail.com>
References: <c69873f9-091f-f863-5f94-68d870285919@gmail.com> <CAF+90c8E_eO1xWLHexNxTFEvFu6DhNyvanTjsGxZ5Ge8aCK0KA@mail.gmail.com>
Date: Sun, 17 Jul 2016 17:28:16 -0600
Message-ID: <CAFMT4NqGykfZXFM=BO-xhbP0pO_+SDqmnFwLztd6cpbWqU5t3A@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Idea: Function autoloading using dummy namespaces
From: levim@php.net (Levi Morrison)

> I don't think this is realistic.

I'll come back to this one in a moment.

> As such:
>
> Option B: foo() in namespace Bar will
> a) Check if Bar\foo() exists
> b) Otherwise check if foo() exists
> c) Otherwise try to load 'Bar\foo'
> d) Otherwise try to load 'foo'
> e) If all fails, throw.
>
> This avoids the autoloading overhead when calling functions from the global
> namespace. However this also means that you cannot autoload a function with
> the same name as a global function through an unqualified call.
>
> In practice, this is probably less problematic than it might sound, because
> realistically function autoloading would likely operate on the
> namespace-level rather than the function level, i.e. if one function from a
> namespace is loaded all of them are, because they are all defined in the
> same file. In such a setting you would never run into this problem as there
> would be no unqualified calls to functions that have not been loaded yet.
> However, it *would* be an issue if you tried to, say, map each function to
> a separate file.

If we are going to use the "one file for all functions" as
justification for defining this behavior a certain way then please
acknowledge it helps both options. One extra autoload from option A is
not a big deal if we are okay with this "one file for all functions"
justification. If we are not okay with that justification then I don't
think option B is viable either.

I think a better option is to try to solve this in 8 by unifying how
functions and classes (and interfaces and traits) work in namespaces.
Ideally the lookup behavior should be the same and all that differs
are the symbol tables being looked in.