Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37689
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
Message-ID: <482E1CB6.7030601@zend.com>
Date: Fri, 16 May 2008 16:45:58 -0700
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Stan Vassilev | FM <sv_forums@fmethod.com>
CC: 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> <208411A24212429683264E1E5C89980F@pc>
In-Reply-To: <208411A24212429683264E1E5C89980F@pc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: 5.3 Namespace resolution rules suggestions
From: stas@zend.com (Stanislav Malyshev)

Hi!

> 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. 

You sound like these usage patterns are figment of my imagination. They 
are not. As for magic quotes and register globals, I understand that's 
very convenient argument to say "your ideas is exactly what lead to 
these", only this has nothing to do with current case. Yes, in past in 
PHP were some decisions that proved to be wrong later. But bringing them 
up in each discussion regardless of its relevance is not going to 
convince anybody.

> 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.

It's not "small hacks". It's supporting the way PHP is used in 100% of 
existing code.

> 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);
> }

What this code is supposed to do? If it's supposed to call namespace's 
json_encode in case global one is not defined, I see nothing wrong with 
it. If it is intended to call globally defined json_encode, then you 
just write ::json_encode, no ifs. The thing is you'd need to do it 
*ONLY* for json_encode, and only because you want to do something 
special with it. The principle is - common case is free, special cases 
are available, but for a "fee" - additional code.

-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com