Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37688
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 69.16.228.148 cause and error)
Message-ID: <208411A24212429683264E1E5C89980F@pc>
To: "internals Mailing List" <internals@lists.php.net>
References: <B3463B2BB0DD4F129EF274EA1DA1135F@pc> <482B9F96.7050908@gmail.com> <482CE5F8.5000700@gmail.com> <4D.AE.00945.5066D284@pb1.pair.com> <482D9F66.4000802@chiaraquartet.net> <fe05d1540805160823o277d79afga91c4bc83de0432@mail.gmail.com> <2DA61F1F6DB245F5A628540F51AAE45F@pc> <482DDF8F.7070005@zend.com>
Date: Sat, 17 May 2008 02:30:54 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="ISO-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: 5.3 Namespace resolution rules suggestions
From: sv_forums@fmethod.com ("Stan Vassilev | FM")

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