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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
