Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:38749 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 98302 invoked from network); 4 Jul 2008 08:28:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Jul 2008 08:28:59 -0000 Authentication-Results: pb1.pair.com header.from=lars@strojny.net; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=lars@strojny.net; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain strojny.net designates 78.46.69.2 as permitted sender) X-PHP-List-Original-Sender: lars@strojny.net X-Host-Fingerprint: 78.46.69.2 milch.schokokeks.org Received: from [78.46.69.2] ([78.46.69.2:37494] helo=milch.schokokeks.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CE/BF-14155-A4FDD684 for ; Fri, 04 Jul 2008 04:28:59 -0400 Received: from [10.88.8.183] (colt-d53d2146.colt.mediaventures.de [::ffff:213.61.33.70]) (AUTH: PLAIN lars@schokokeks.org, SSL: TLSv1/SSLv3,256bits,CAMELLIA256-SHA) by milch.schokokeks.org with esmtp; Fri, 04 Jul 2008 10:28:55 +0200 id 000000000000C013.00000000486DDF47.00002D46 To: Derick Rethans Cc: php-dev List In-Reply-To: References: <1215076043.7021.10.camel@localhost> Date: Fri, 04 Jul 2008 10:28:55 +0200 Message-ID: <1215160135.8875.14.camel@localhost> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=_milch.schokokeks.org-11590-1215160135-0001-2" X-Mailer: Evolution 2.22.2 Subject: Re: [PHP-DEV] [RFC] Namespaces for internal classes From: lars@strojny.net (Lars Strojny) --=_milch.schokokeks.org-11590-1215160135-0001-2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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. cu, Lars --=_milch.schokokeks.org-11590-1215160135-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) iQIcBAABAgAGBQJIbd9HAAoJECQPF+sCY6wHtK4P/1c/9SQrcNMHl9RvJZAwUxaH yjs9inqA2pD7VrITsDEbTqweyOu6/VombXb83wFJlN2m//1db2i7cEFGEthFnJ8Z fuqL/mbpfzyCAOs4MLZCd5qPbo3UieQoLEH1Tju208WmAEY7FSsndIkMVZfgUDA/ KezP/pdILK1GyJjwHsOJY3pkJGtOSrBeTXFiRM8GrZGq/E229hw7IivjnyDu70hn hcfonve4ciFd5M71Vhbf0HlSRaymgcHYl+Rz55peduaE3C2lXDZaT/LO7Ubu71fo wFIp6B5L+AaWYFzp3B3irymlDJzAqF8I3wp/O/KO0o9Z/R1dThAVe02gGRP23Dbv g5cRhUW83uscmjWix0czLMFgIiRz3Os0mxghxDTEVhC7ISdo54Rcrjr3Ag2YLhjv RiBGqb4nYmbIhA57UG8BZxmOcu9flHEjk2UZEzz40KGqL3X2SECNc4IwrMTppZJj ZkMOGmh64/TemsnSeWnoSH1feBQQNx6TwOgtfyOHXFZ8weSxXgZMaE/sWPTKOiNg NSzc43l4qgmmmOWia44roWQIjGOipP5x/2B+q23zmmGSgM5zCm7uwfVkU7PD25Xi 7W0WRsdhkuMI7TzAWh2oh7S4hz23K+pQnWss8bRgK5i3yAX5BWAF6hzdEpssrN3R ELuwGv+m3Cs6SX34Bn2e =OLDN -----END PGP SIGNATURE----- --=_milch.schokokeks.org-11590-1215160135-0001-2--