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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
