Re: 5.3 Namespace resolution rules suggestions

Hi Stan, I made a proposal and patch a few months ago at http://news.php.net/php.internals/34097, which Julian later adapted to a more recent version of PHP 5.3 at the time at http://news.php.net/php.internals/36822 (don't know if the patch still applies cleanly). Unfortunately I haven't received many comments on the patch nor any reasons on why it shouldn't be merged. Let me know what you think of the resolution rules I proposed. -- Jessie Hernandez Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359&r=222727282) Stan Vassilev | FM wrote: > 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