</endnamespacediscussion>

David Grudl wrote:

I hope it is only very bad joke :-(

namespace myNamespace;

class theLoader
{
function load($class) { ... }
}

// somewhere else
spl_autoload_register(array("myNamespace\theLoader", "load"));
-> registers myNamespace<tab>heLoader::load()

Fortunately, there is a simple workaround:

spl_autoload_register(array('myNamespace\theLoader', 'load'));

or slightly less simple:

spl_autoload_register(array("myNamespace\theLoader", "load"));

Greg

Ok, for short: "Cry havoc, and let loose the dogs of war." The fact that
they chose '' instead of ::: or anything else is going to be a killer to
teach for novice PHP devs.

Just my 0.02$ ...

-----Original Message-----
From: Stan Vassilev | FM [mailto:sv_forums@fmethod.com]
Sent: Sunday, October 26, 2008 10:04 AM
To: PHP internals
Subject: Re: [PHP-DEV] </endnamespacediscussion>

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

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

You're welcome.

Benjamin Schulz wrote:

Thanks for another great argument to move away from PHP asap.

that we have decided to go with backslash as new separator for
namespaces.

2008/10/27 Cristian Rodríguez crrodriguez@suse.de:

Im truly sorry, looking at the horrendously ugly example code, I just
hope the average joe programmer dont touch this feature and stay with
class prefixes for sanity sake.

If by "don't touch" you mean "don't even try" then I'd say it's not a
very good advice.

I've tried Greg's patch [1] the day this thread was created. Even if I
wasn't terribly happy with the choice (still beats the triple-colon in
my opinion, though), even if I had to spend half an hour to convert my
files to the new namespace separator (that's why it's called the
"bleeding" edge I guess) and even if the first few minutes were
uncomfortable, I'm now 36 hours after committing the changes to my
personal code repository and the backslash doesn't even feel weird
anymore. You just have to use it.

It took a while to get used to PHP 5's object model, it will take a
while to get used to PHP 5.3's namespacing.

-JD

[1] http://wiki.php.net/rfc/backslashnamespaces#patch

2008/10/27 Ilia Alshanetsky ilia@prohost.org

Thanks for all your hard work guys. While \ separator is a bit weird, I
wholeheartedly support the decision to use a distinct separator for
namespaces.

Totally agree, Originally I thought WTF they've chosen \ but once I got past
all the FUD and really thought about it then it makes sense. Thanks for
stepping up to the plate and making what wasn't a very easy decision!

Regards

Marco