Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94539
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAFMT4NqGykfZXFM=BO-xhbP0pO_+SDqmnFwLztd6cpbWqU5t3A@mail.gmail.com>
References: <c69873f9-091f-f863-5f94-68d870285919@gmail.com>
 <CAF+90c8E_eO1xWLHexNxTFEvFu6DhNyvanTjsGxZ5Ge8aCK0KA@mail.gmail.com> <CAFMT4NqGykfZXFM=BO-xhbP0pO_+SDqmnFwLztd6cpbWqU5t3A@mail.gmail.com>
Date: Mon, 18 Jul 2016 01:55:09 +0200
Message-ID: <CAF+90c_UBnZkkWfPGR37A0rcUNZQfSReU6=4nd0TVKTXY5Txig@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113d3852fd316d0537dd9476
Subject: Re: [PHP-DEV] Idea: Function autoloading using dummy namespaces
From: nikita.ppv@gmail.com (Nikita Popov)

--001a113d3852fd316d0537dd9476
Content-Type: text/plain; charset=UTF-8

On Mon, Jul 18, 2016 at 1:28 AM, Levi Morrison <levim@php.net> wrote:

> > 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 don't follow what you mean here. The problem is not the case where the
unqualified call actually refers to a namespaced function. The problem is
the case where it refers to a global function (which is also far more
likely). In this case option A requires that we invoke the autoloader for
each call. A relaxed variant would only invoke the autoloader once for each
call, assuming that a function that is not loadable at one time will never
become loadable (which is of course a significant restriction). The former
variant would be prohibitively slow. The latter is more realistic, but I
expect it to have non-trivial performance impact nonetheless.

As all of this only applies to the case where the unqualified call refers
to a global function, it does not actually matter how you namespace things
(single or multiple files). As such, I'm not sure I understand your
argument.


> 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.
>

Are you suggesting that we require global function references to be written
as fully qualified names? This would be a huge BC break for namespaced code.

Regards,
Nikita

--001a113d3852fd316d0537dd9476--