Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33987
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: Thu, 13 Dec 2007 11:12:35 +0100 (CET)
To: PHP Developers Mailing List <internals@lists.php.net>
cc: cellog@php.net
In-Reply-To: <alpine.DEB.0.98.0712042315260.20300@kossu.ez.no>
Message-ID: <alpine.DEB.0.98.0712131110050.27826@kossu.ez.no>
References: <alpine.DEB.0.98.0712042315260.20300@kossu.ez.no>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=UTF-8
Subject: Re: [PHP-DEV] RFC: Dropping Namespace
From: derick@php.net (Derick Rethans)

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


-- 
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org