Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109739
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <CAEPJdukDAbNSjtS=VdjaMmUtA1fwN0eJ=EXKziTs3dgWUWZ4Rw@mail.gmail.com>
Date: Tue, 21 Apr 2020 01:29:27 -0400
Cc: PHP Internals List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <EDB49720-BC4E-4190-A3E5-66B765A770AD@newclarity.net>
References: <CABdc3WoTeO4eTAoHCfqKyy8PWjrn97w9JXXhD88c3O9xPzp7QQ@mail.gmail.com>
 <CAEPJdukDAbNSjtS=VdjaMmUtA1fwN0eJ=EXKziTs3dgWUWZ4Rw@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] PHP Namespace in core
From: mike@newclarity.net (Mike Schinkel)

I have been wondering for a while why PHP does not officially recognize =
a \PHP namespace.

The inconsistency people have mentioned feels like a fair tradeoff for =
allowing new core classes to be cleanly-named and easier to understand.

And a \PHP namespace would allow RFCs to never need worry about =
conflicting with userland class names again. =20

The one thing I would ask the authors:=20

- Why limit it to "tightly coupled to the PHP engine?"=20
- Why not just say "any new core classes that are approved to use it?"

After all, sometimes a namespace is just a namespace. Seems like a =
winner to me.

-Mike=