The use statement behavior currently supports only class names aliasing. Functions and constants have to referred with full name, although these too can be namespaced.
Right, this was an conscious decision - since there are much more functions than classes, importing functions into global space is much higher risk (and utility functions in OO libraries are less frequently used externally then classes).
resolution rules will bring much headaches to users. For starters you'll have to make a habit of prefixing :: to all internal function calls (such as ::count, ::strlen, etc). This way will be safer for creating php libraries,
You can do it, but mandating it is not a good idea, which was discussed here.
---- Constrained scope for imports is unpractical ---- When trying to refactor code to use namespaces, as a test, I also found that having the use statement limited to outer scope is unpractical. One necessary addition, which is not very complicated, is to have an extra scope for use statements, such as imports in a function scope. It's only a matter of keeping an extra table for the function scope in compile time.
It would make PHP code more complicated, so I'm not sure it is a good addition.
---- Namespaces as nested classes? ---- Reading about how the previous implementation of namespaces went down the drain, one recurring though in some users and developers caught my attention. Maybe namespaces and nested classes should be one and the same thing in php. Considering that many are using classes as namespaces for
The issue of nested classes was discussed numerous times and it never proved to be a good idea.
---- Type hints, improvements could help drastically improve performance ---- I thought much about type hints. Right now they are only seen as syntactic sugar for system designers, and something that reduces performance. Actually quite the opposite can be achieved, but not with the current implementation of type hinting. The guys behind flash 9 obtained a 10x improvement in performance thanks to type hinting. Actually doing the same with PHP is quite sensible, since one of the bottlenecks for performance is the zval.
It would be nice to hear what did you mean by that.
Knowing before hand that the variable is a native type, a just in time native compile can be done to drastically improve performance.
I know of no efforts for JIT compiling PHP, so I guess if we'd want to get something there, we'd better start with having any JIT at all and not with modifying the language for possible imaginary JIT compiler.
---- Taints ---- Last but not least, I thought about taints. Since PHP6 will remove safe mode and magic quotes, as far as I know, if nothing else is there to prevent users from being users, well PHP6 might be considered too insecure. Taints
I must note that the primary reason for removal of "safe mode" and "magic quotes" were the fact that it does not improve security. Thus, PHP 6 is not less secure than any versions with these capabilities. Primary fault of "magic quotes" was that it tried to solve input filtering problem without taking into account how variables are used, better input filtering extension takes care of that. Primary fault of "safe mode" was that it tried to bring into PHP things that can not be properly done in PHP, since PHP engine can not control extensions.
much can be added to zval without suffering the consequences, and a simple model of tainted/not tainted is not safe enough, as there are many taints to be considered (XSS, SQL injection, HTML injection to say the least).
That's what current proposal is doing. I can not have an opinion of how good it does it since I didn't finish reviewing it yet.
-- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
