Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40508
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 208.83.222.18 cause and error)
Message-ID: <48CCA3B1.5060602@chiaraquartet.net>
Date: Sun, 14 Sep 2008 00:40:01 -0500
User-Agent: Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: Stanislav Malyshev <stas@zend.com>
CC: internals@lists.php.net
References: <48C59D5C.4050507@chiaraquartet.net> <48C5A909.4030502@zend.com> <48C602D5.6020704@chiaraquartet.net> <48C6A6AA.7050003@zend.com> <48C9F2F6.4080007@chiaraquartet.net> <48CAC1EF.2090501@zend.com> <48CB20BA.4070609@chiaraquartet.net> <48CC85D7.4010401@zend.com>
In-Reply-To: <48CC85D7.4010401@zend.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH] Re: [PHP-DEV] namespace examples (solving name resolutionorderissues)
From: greg@chiaraquartet.net (Gregory Beaver)

Stanislav Malyshev wrote:
> Hi!
>
>> In other words, there is simply no comparison.  Userspace class usage
>> outnumbers internal class usage by an order of magnitude in typical OO
>> PHP code.
>
> I didn't claim userspace class usage outnumbers internal class usage
> or otherwise. What I claimed is that since we have a lot of files
> (framework has 1821, as you very helpfully pointed out) and those use
> 950 instances of internals classes, application using Framework has
> big chance to "score" hundreds of uncacheable autoloads. And that is
> not counting user code, which would add to the problem.
Right, and since you pointed out this limitation and then found another
example that has the same problem that cannot be solved (non-autoload
with load order determining what classname is instantiated), that
invalidates any possible approach.  I was trying to say that this leaves
us with only 1 choice, which is whether to use the name resolution you
proposed or stick with the current one.  Currently we have:

1) check current namespace
2) check internal
3) autoload if possible
4) fail

I remind all of the name resolution for classes that you proposed:

1) check current namespace
2) autoload if possible
3) fail

Since my little script proved that the ratio of userspace vs. internal
classes heavily favors userspace classes, this load order makes sense. 
However, I want to point out that it doesn't take a script to prove that
the ratio of userspace functions vs. internal functions is exactly the
opposite (far more internal functions vs. userspace functions), so I
propose we have separate name resolution for classes and functions

classes:

1) check current namespace
2) autoload if possible
3) fail

functions:

1) check current namespace
2) check internal
3) fail

Load order would matter for functions, but the risk is worth the benefit.

I believe the initial implementation of namespaces had this order for
classes, so Dmitry's first patch would have the necessary changes.

Greg