Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38755
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 83.243.58.163 as permitted sender)
To: Lars Strojny <lars@strojny.net>
Cc: Derick Rethans <derick@php.net>, php-dev List <internals@lists.php.net>
In-Reply-To: <1215160135.8875.14.camel@localhost>
References: <1215076043.7021.10.camel@localhost>
	 <alpine.DEB.0.98.0807041013280.6963@kossu.ez.no>
	 <1215160135.8875.14.camel@localhost>
Content-Type: text/plain
Date: Fri, 04 Jul 2008 11:15:28 +0200
Message-ID: <1215162928.32294.5.camel@goldfinger.johannes.nop>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Namespaces for internal classes
From: johannes@php.net (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Fri, 2008-07-04 at 10:28 +0200, Lars Strojny wrote:
> Hi Derick,
> 
> Am Freitag, den 04.07.2008, 10:14 +0200 schrieb Derick Rethans:
> > I'd say this is a BIG no-no. PHP owns the top-level namespace. Why
> > make things harder? And on top of that, you're suggesting just to
> > break code for no good reason in "Backwards compatibility and other
> > constraints".
> 
> Quoting the proposal: "The current names are available as deprecated
> aliases until their removal". This means that until we decide to remove
> the old names, the current ones are available. I'm currently
> investigating how to implement an ADD_DEPRECATED_CLASS_ALIAS-macro.
> Classes/interfaces created with this warning would trigger an
> E_DEPRECATED warning.

That's not entirely true, there are minor BC breaks: Let's say Bar is an
alias for Foo::Bar. now to $r = new ReflectionClass('Bar'); echo
$r->getName(); and you'll get 'Foo::Bar' as that's the name in the CE,
same goes for error messages, stack traces, ... (I'Ve seen people
parsing them...)

johannes