Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38579
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.94.239.7 as permitted sender)
Date: Tue, 24 Jun 2008 16:36:12 +0200 (CEST)
To: Gregory Beaver <greg@chiaraquartet.net>
cc: Andi Gutmans <andi@zend.com>, Stanislav Malyshev <stas@zend.com>,
        Dmitry Stogov <dmitry@zend.com>,
        internals Mailing List <internals@lists.php.net>
In-Reply-To: <485BD1C0.8040302@chiaraquartet.net>
Message-ID: <alpine.DEB.0.98.0806241634430.16594@kossu.ez.no>
References: <485BD1C0.8040302@chiaraquartet.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=UTF-8
Subject: Re: [PHP-DEV] simple solution to another namespace conundrum?
From: derick@php.net (Derick Rethans)

On Fri, 20 Jun 2008, Gregory Beaver wrote:

> The user is obviously intentionally creating a "DateTime" class, and
> doesn't care about the internal classname in this script.
> 
> The attached patch against PHP_5_3 would fix the issue by eliminating
> the check for conflict with CG(class_table) in the global namespace for
> internal classes.  It however preserves this check for userspace classes
> so that (for instance) php-src/tests/Zend/ns_030.phpt does not fail. 
> The basic idea is that we do have control over the userspace classes we
> include, but have no control over the internal classes.

I am not so sure this is a good idea. I mean, for the developer that 
writes the code it's obvious that his version of DateTime is used. But 
for a second developer to come back later this could be a great WTF 
factor a few years down the road - wondering why the DateTime 
documentation on php.net doesn't match with what the class does. 

regards,
Derick