Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38765
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: <1215163596.8875.22.camel@localhost>
References: <1215076043.7021.10.camel@localhost>
	 <alpine.DEB.0.98.0807041013280.6963@kossu.ez.no>
	 <1215160135.8875.14.camel@localhost>
	 <1215162928.32294.5.camel@goldfinger.johannes.nop>
	 <1215163596.8875.22.camel@localhost>
Content-Type: text/plain; charset=utf-8
Date: Fri, 04 Jul 2008 13:56:43 +0200
Message-ID: <1215172604.32294.34.camel@goldfinger.johannes.nop>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Namespaces for internal classes
From: johannes@php.net (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

Hi,

On Fri, 2008-07-04 at 11:26 +0200, Lars Strojny wrote:
> Am Freitag, den 04.07.2008, 11:15 +0200 schrieb Johannes Schlüter:
> [...]
> > 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...)
> 
> Didn't thought of that, thanks for the heads up. In your opinion, would
> that be a show stopper?

Depends ;-)
Main point: There's no such thing as "no BC break". So we have to decide
whether that BC break (hoping it's the only one) is less a problem than
having an inconsistent naming scheme. (... wait - isn't PHP famous for
being inconsistent?) The question there is: Where do we want to go
tomorrow? Do we want to namespace internal stuff? All of it? Or do we
still want to own the global namespace and put internal classes there?
As long as that isn't decided it's hard to make a decision about
aliasing.

So I'd say we need the RFC which defines rules for future stuff
(All/"non-core" parts/nothing in namespaces) and then the consequences
for existing stuff.

johannes