Hi, I'm looking at the current namespace resolution rules here: http://www.php.net/manual/en/language.namespaces.rules.php
Something that bothers me is that for the first time in PHP we introduce a hard difference in how internal functions and user functions are resolved/called: ::foo(); // resolves as user function in global namespace foo(); // can resolve as function in the current namespace, else as internal function Whether a function/class is internal is implementation detail that I believe shouldn't be forced in such a fashion in user code. It makes people to check/think whether a function is internal or not, additionally to thinking about namespace scope. It's unneded complexity. If you check the PHP manual comments, you'll notice people often introduce PHP userspace equivalents to various functions and extensions, there's for example a full PHP-only implementation of curl: http://code.blitzaffe.com/pages/phpclasses/files/libcurl_emulator_52-7 There was also a wave of drop-in replacements for PHP5 function in PHP4, or for example json_en/decode() drop-in for PHP 5.1 users who don't have the PECL extension. None of those will be possible in namespace scope in 5.3, and a developer will need to have plenty of special cases in code or special factories, if it's not known in advance whether a class/function will be internal or not. To further convolute things, the drop-ins will work if *not* in namespace context. A second problem is one of future-proofing. Many of the procedural API-s in PHP4 saw transition to OOP in PHP5. If namespaces have success and are adopted widely, we may see new or existing internal functions make similar transitions to being namespaced. This will leave "global internal" function stick our like a sore thumb, as a solitary special case with specific syntax, as opposed to all other cases we have. A third problem is one of performance. Every time a developer calls an internal function, an attempt will be made to resolve it to a user function in the current namespace, and only then call the internal function. Typical PHP code contains plenty of internal function calls, while I believe the novelty of being able to transparently override intenral functions will wear off quickly and be used quite sparingly (and quite likely be considered a bad practice, leading to confusing code). What I suggest: ::foo(); // to resolve a user or internal function in global namespace (in namespace context) foo(); // to only resolve at compile time, in the current namespace (in namespace context) Much simpler to understand, more future-proofed, faster (more cases can be covered by compile-time resolution), and allows PHP drop-ins for binary/internal functionality. To recap, problems with the current approach that are resolved by what I suggest: 1. Exposing internal/user functions in userspace code as two different things. 2. Drop-in replacements for internal functionality won't work in namespace context. 3. Problems when internal functions/classes start showing up in namespaces in the future. 4. Performance hit, as more things need to be resolved at runtime that it's needed. Please give me your feedback and use cases. Regards, Stan Vassilev
