Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33989
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: <476123EA.9030601@zend.com>
Date: Thu, 13 Dec 2007 15:22:02 +0300
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Derick Rethans <derick@php.net>
CC: PHP Developers Mailing List <internals@lists.php.net>, 
 cellog@php.net
References: <alpine.DEB.0.98.0712042315260.20300@kossu.ez.no> <alpine.DEB.0.98.0712131110050.27826@kossu.ez.no>
In-Reply-To: <alpine.DEB.0.98.0712131110050.27826@kossu.ez.no>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Dropping Namespace
From: dmitry@zend.com (Dmitry Stogov)

Hi Derick,

Now, you cannot override existing classes with "use" statement.
However inside a namespace you don't have internal classes and "use" 
works just fine.

<?php
namespace Foo;
use myNamespace::Bar as stdClass;
?>

I think it is clear decision.
If you like to override internal classes just write your code in your 
own namespace.

Allowing class overriding is possible from technical point of view (it 
is disabled on purpose), but it'll give more mess than advantage.

Thanks. Dmitry.

Derick Rethans wrote:
> Hei,
> 
> now some patches by Greg and Dmitry made it into CVS, some of the things 
> in my mail have been resolved, however, we still need to come up with a 
> solution to the 1st and most important issue:
> 
> On Tue, 4 Dec 2007, Derick Rethans wrote:
> 
>> 1. As it is impossible to do "use XXX as NativeClass" we get to the 
>>    point where we'd have to namespace new internal native classes
>>    otherwise we might introduce BC breaks. AFAIK, we've always said that
>>    PHP reserves the globals space for it's own use (see also:
>>    http://www.php.net/manual/en/userlandnaming.rules.php). In case we do
>>    add new classes (an example could be DateTimeSpan), they should of
>>    course follow the same format as already existing classes in the
>>    extension (DateTime, DateTimeZone). However introducing the new class
>>    DateTimeSpan might break people's code that do things like:
>>
>> 	<?php
>> 	use myNamespace::DateTimeZone as DateTimeZone;
>> 	?>
>>
>>    feature versions of people would then show:
>>
>> 	Fatal error: Cannot use myNamespace::DateTimeZone as DomDocument 
>> 	because	the name is already in use.
>>
>>    It would be silly to require to have to do this:
>>
>> 	- Create a class PHP::Date::TimeSpan
>> 	- In your scripts:
>> 	  use PHP::Date::TimeSpan
>>
>>   But with the current implementation, this seems to be the only non-BC
>>   breaking solution. If we chose *not* to require this silly namespacing
>>   of internal classes, users instead have to do this:
>>
>> 	<?php
>> 	use myNamespace::DateTimeZone as myDateTimeZone;
>> 	?>
>>
>>   Basically prefixing the classnames... This you can already do just
>>   fine without namespaces.
> 
> I know Greg has some ideas with __php__ as recommendation, but I find it 
> a bit clumsy still. Perhaps Greg can summarize how it will address the 
> above issue?
> 
> regards,
> Derick
> 
>