Hi Stan, I realized I missed 2 of your points, response below:
Stan Vassilev | FM wrote: > Hi, > > Multiple namespaces per file were introduced to allow certain > workflows in PEAR and frameworks like Symphony which can combine > multiple classes and namespaces in a single package. > > They work like this: > > > namespace X; > > ... > > namespace Y; > > ... > > > The problem is, no one thought of scoping "use" statements, so now > those merged files share their "use" imports, thus breaking all the > code where collisions occur. > > Also we have the problems with name resolution of internal vs user > classes and autoloaders, discussed here. I just posted a patch that solves this problem, and a few minutes ago forwarded two messages that further clarify how the patch works and why it is a good solution to the problem. > And we also have the non-intuitive differentiation between resolving > functions/classes/constant which will most likely lead people to > believe functions/constants aren't supported in any way in namespaces > (if they try, and it doesn't work, they won't try second time). The other 2 patches I have posted solve these issues decisively. Since these would change namespace edge cases and introduce a new way to import, I think an alpha3 is warranted. The name resolution changes should not affect any existing working code that utilizes namespaces, but should make it possible to do autoload without having to "use" every single namespace class. The patches do need review, and I am certain the patch introducing function::blah::here() could be better written, and needs a Sara/Dmitry type to take a quick look and say what could be done to improve it. However, I don't think these facts warrant removal of the key feature of namespaces, especially since they are relatively easy to solve - these patches did not take many hours to whip up, and do not change very much. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
