Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37684
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: <482DDF8F.7070005@zend.com>
Date: Fri, 16 May 2008 12:25:03 -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>
In-Reply-To: <2DA61F1F6DB245F5A628540F51AAE45F@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!

> 1) functions, constants and classes should use the same resolution 
> rules. Making special cases just for some of them, or just for user or 
> just internal ones will lead to confusion.

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.

> 2) can someone please explain why is it useful to override internal 
> function inside a namespace. Isn't it better to explicitly refer to 
> global functions as global, which would allow compile-time resolution in 
> a lot more cases than now.

It is not better, since it means that if you have non-namespace code 
library, you would have to edit a lot of code to convert it to namespace 
- you would have to edit every function call. Aaside form looking 
awkward, it is a lot of work. Of course, you can still do it, but you 
shouldn't have to.
Since OO libraries rarely use (read: should never use, unless they have 
very super-duper good reason to, and even then probably not) global 
non-internal functions, usage pattern for internal and non-internal 
functions differ.

I know this does not account for the use case of having some function 
both internal and implemented in PHP. This is not a frequent use case, 
but it happens. I see it much less frequent use case than converting 
non-namespaced code to namespaces. In this case, you will have to do 
some additional work - you'd have to prepend :: to any global function 
you do such tricks on. It's not worse than prepending :: to *ALL* 
functions as you seem to suggest.

> 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?
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com