Hello Gregory, Sunday, September 14, 2008, 7:40:01 AM, you wrote:
> 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 If we no longer check in ternal then: a) Functions and classes have a different load behavior - not just support through autoload (which could in some form be added for functions later. b) we could very easy add nested namespaces as then there is no more conflict in that. c) is forcing people to always write the long way for internal classes what we want? I doubt it because practically it means we chaqnge the name of all internal classes in the presence of namespaces and the current load order was deigned to prevent that iirc. my conclusion is that i prefer the state of the art as it is and well i am not yet convinced we need functions in namespaces. But it appears there are many friends and I am not against it. So I propose we do it as compatible as possible. And that means they should follow the same name lookup pattern. And if that means a tiny bit of slowdown so be it. That is better then just another inconsistency. marcus > 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 Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
