Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38583
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <48610D08.2030604@lerdorf.com>
Date: Tue, 24 Jun 2008 08:04:40 -0700
User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604)
MIME-Version: 1.0
To: Derick Rethans <derick@php.net>
CC: internals Mailing List <internals@lists.php.net>
References: <485BD1C0.8040302@chiaraquartet.net>  <alpine.DEB.0.98.0806241634430.16594@kossu.ez.no> <cd5680a20806240747h5b4eda5ncd24cd72c21e6799@mail.gmail.com> <alpine.DEB.0.98.0806241651480.16594@kossu.ez.no>
In-Reply-To: <alpine.DEB.0.98.0806241651480.16594@kossu.ez.no>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] simple solution to another namespace conundrum?
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Derick Rethans wrote:
> On Tue, 24 Jun 2008, Alexey Zakhlestin wrote:
> 
>> On Tue, Jun 24, 2008 at 6:36 PM, Derick Rethans <derick@php.net> wrote:
>>> 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.
>> it won't be a serious 'wtf', as on the top of the file, there would be
>> some kind of
>> use MySuperLibrary::DateTime;
> 
> I know, but 400 lines down in the code you can't really see that. This 
> addition might fix the immediate issue - but it doesn't make life easier 
> for the developers that have to maintain the code. Even less if they're 
> not aware that stuff is namespaced.

If we don't allow it to work this way, then I really don't see the point 
in namespaces at all, which I assume is the point you are trying to 
make.  But, assuming at this point that we do want namespaces, then we 
have to make them work, and by its very nature namespacing involves code 
obfuscation.  With or without this change, having the same userspace 
functions in different namespaces provides the same level of code 
obfuscation where a line of code read in isolation is impossible to 
resolve without looking at its namespace context.

-Rasmus