Re: Re: 5.3 Namespace resolution rules suggestions

Hi,

No, not necessarily. Functions, constants and classes have different traditional usage patterns in PHP, and as such may have resolution rules that follow these patterns. I don't say we should look for making them different, but if necessary, we should use rules that benefit the most frequent use cases, even if it upsets some purists that like everything being lined up and painted the same color.

I find that line of thinking unfortunate. I'm not a purist, if I was, my list of issues with namespaces would be far longer than it actually is. Trying to fudge the behavior of PHP to fit some kind of presumed usage patterns is what got us features like magic quotes and register globals. Namespaces were introduced to solve the problems of large scale projects, and I think anyone on this list can agree that on a large scale project, small hacks like these are a hindrance and not an aid.

globally a PHP-only clone of a missing binary/internal features is a far more predictable behaviour, and people use it a *lot* right now. Do we

What do you mean by "predictable"? Current behavior is 100% predictable and described in the manual.

really want to break this in 5.3?

We don't, and we won't. You'd just need to alter your code slightly to achieve same behavior. As I understood, the proposal is to force *ALL* functions to work this way - how it's better?

Please can you support this with an example? Imagine we introduced namespaces as they are in 5.0. I want to use json_encode but I have PHP 5.1 and don't have the PECL extension. What I can do currently is simply drop one of the many PHP-only json_encode/json_decode replacements and code away without being bothered whether in my specific environment json_encode/decode is internal or user. But in namespace context I'll have to do something along the lines of: if (function_exists('json_encode')) { $encoded = json_encode($raw); } else { $encoded = ::json_encode($raw); } I hope this helps to understand the problem. Please correct this code slightly, as you suggest, to fix this problem. Regards, Stan Vassilev