Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41377
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 69.16.228.148 cause and error)
Message-ID: <9373E34A42AC4CE0A65E512A61897512@pc>
To: "PHP internals" <internals@lists.php.net>
References: <46BD96DF-B594-490C-9812-D7ACDD976205@pooteeweet.org>
Date: Sun, 26 Oct 2008 10:04:02 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] </endnamespacediscussion>
From: sv_forums@fmethod.com ("Stan Vassilev | FM")


Hi,

I want to thank you all for opting for the technically sound, clear and 
performant solution. Of course some users will never understand the precise 
reasons :: was avoided, but it's something we'll have to live with, given 
some past design choices in PHP.

Regarding "foo\tbar" turning into "foo[tab]bar", I just wanted to throw it 
out there, although I don't think it's a great idea. We have only few escape 
combinations in string literals which can also be in a valid identifier:

\t  \n  \r

There are also some which aren't a problem since they can't be in a valid 
identifier:

\x..  \0  \\  \$  \'  \"  \{..} etc.

So the problem is with exactly three combos:  \t, \n and \r. In the few 
places PHP takes class/function identifiers as strings, TAB, CR and LF could 
be interpolated back into the two characters they express, since TAB, CR and 
LF aren't valid on their own in identifiers, so ambiguity is not possible.

Those places of the top of my mind are:  new $class(), $class::property, 
call_user_*(), _autoload, and all other places accepting callbacks.

This would mean both of those will work correctly:  "foo\\tbar" and 
"foo\tbar" when used as an identifier.

Think of it as a plan B in case people cause a big fuss about it (which I 
think they won't: think about escaping of windows file paths and escaping in 
regex pattern, we're doing just fine there).

Regards,
Stan Vassilev