Hi guys,
I'm really interested to read the IRC conversation logs.
Does anyone recorded it?
Regards,
On Sun, Oct 26, 2008 at 1:29 PM, Greg Beaver <[EMAIL PROTECTED]> wrote:
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: [EMAIL PROTECTED]
URL: http://blog.bisna.com
Rio de Janeiro - RJ/Brazil
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
