Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41385
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 208.83.222.18 cause and error)
Message-ID: <49048CCB.2090407@chiaraquartet.net>
Date: Sun, 26 Oct 2008 10:29:15 -0500
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070807)
MIME-Version: 1.0
To: Stan Vassilev | FM <sv_forums@fmethod.com>
CC: PHP internals <internals@lists.php.net>
References: <46BD96DF-B594-490C-9812-D7ACDD976205@pooteeweet.org> <9373E34A42AC4CE0A65E512A61897512@pc>
In-Reply-To: <9373E34A42AC4CE0A65E512A61897512@pc>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] </endnamespacediscussion>
From: greg@chiaraquartet.net (Greg Beaver)

Stan Vassilev | FM wrote:
> 
> 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.

there are other escape sequences (such as \f)

> 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).

I don't see this as a real problem, simply because when one makes a
mistake, it is obvious.  A fatal error is displayed with the offending
class name/function name/constant name (yes, namespace constants die
with fatal error if they are not found, unlike traditional un-namespaced
constants).  Although it may be possible to magically replace escaped
characters, this could have unintended side effects.  For instance, if a
user is instantiating a class based on external input, it would
introduce a new way to have unexpected behavior, as newlines would be
converted to \n or \r.

As I stated in my last message on the subject, the best approach for any
string is to always use single quotes.  You're far less likely to run
into trouble.  This has been true for years, and is not changed by
namespaces or any other addition in 5.3

Shall we let this one go?

Greg