Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] </endnamespacediscussion>

Posted by Lukas Kahwe Smith 
Lukas Kahwe Smith
[PHP-DEV] </endnamespacediscussion>
October 25, 2008 08:10PM
Hi all,

Thx to the initiative of Scott and Steph we had an IRC discussion with
several code developers. The result is that we have decided to go with
backslash as new separator for namespaces. The IRC log that
illustrates why we in the end decided to go with changing the
separator and the final decision on backslash can be found on the wiki
[1].

Greg is working on a patch, however Dmitry said he will assist even
though he was actually opposed to the decision we made in the end. I
very much appreciate Dmitry accepting this decision in such a
professional manner.

At the same time I hope that all people that have participated in this
discussion accept this decision as one that was made by a sufficiently
large subset of the development community. We did not take the
decision lightly but we felt confident that this decision is for the
best of PHP going forward.

As the patch is still under development it is yet unclear how this
will affect the scheduling PHP 5.3.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

[1] http://wiki.php.net/rfc/namespaceseparator

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
David Grudl
[PHP-DEV] Re: </endnamespacediscussion>
October 25, 2008 11:10PM
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()


David Grudl


-------- P?vodní zpráva --------
P?edm?t: </endnamespacediscussion>
Od: mls@pooteeweet.org (Lukas Kahwe Smith)
Komu:
Datum: 25.10.2008 20:07

> Hi all,
>
> Thx to the initiative of Scott and Steph we had an IRC discussion with
> several code developers. The result is that we have decided to go with
> backslash as new separator for namespaces. The IRC log that illustrates
> why we in the end decided to go with changing the separator and the
> final decision on backslash can be found on the wiki [1].


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Gregory Beaver
[PHP-DEV] Re: </endnamespacediscussion>
October 25, 2008 11:15PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stan Vassilev | FM
Re: [PHP-DEV] </endnamespacediscussion>
October 26, 2008 09:10AM
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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Catalin Zamfir Alexandru | KIT Software CAZ
RE: [PHP-DEV] </endnamespacediscussion>
October 26, 2008 09:35AM
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:[email protected]]
> 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
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Benjamin Schulz
Re: [PHP-DEV] </endnamespacediscussion>
October 26, 2008 04:25PM
Thanks for another great argument to move away from PHP asap.

On 25.10.2008, at 20:07, Lukas Kahwe Smith wrote:

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Greg Beaver
Re: [PHP-DEV] </endnamespacediscussion>
October 26, 2008 04:30PM
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
Re: [PHP-DEV] </endnamespacediscussion>
October 27, 2008 05:20AM
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: guilhermeblanco@hotmail.com
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
Cristian Rodríguez
Re: [PHP-DEV] </endnamespacediscussion>
October 27, 2008 05:20AM
Lukas Kahwe Smith escribió:
> The result is that we have decided to go with
> backslash as new separator for namespaces.

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.

I understand why there was not other suitable alternative though :-(

My sincere condolences.

--
"A computer is like an Old Testament god, with a lot of rules and no
mercy. "

Cristian Rodríguez R.
Platform/OpenSUSE - Core Services
SUSE LINUX Products GmbH
Research & Development
http://www.opensuse.org/
Attachments:
open | download - signature.asc (267 bytes)
open | download - signature.asc (267 bytes)
Josh Davis
Re: [PHP-DEV] </endnamespacediscussion>
October 27, 2008 05:30AM
2008/10/27 Guilherme Blanco <[email protected]>:
> Hi guys,
>
>
> I'm really interested to read the IRC conversation logs.
> Does anyone recorded it?

If you follow the link [1] from the first mail, you'll find the log
you're looking for in the References section.

[1] http://wiki.php.net/rfc/namespaceseparator

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Josh Davis
Re: [PHP-DEV] </endnamespacediscussion>
October 27, 2008 05:45AM
2008/10/27 Cristian Rodr
Ilia Alshanetsky
Re: [PHP-DEV] </endnamespacediscussion>
October 27, 2008 01:35PM
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.


On 25-Oct-08, at 2:07 PM, Lukas Kahwe Smith wrote:

> Hi all,
>
> Thx to the initiative of Scott and Steph we had an IRC discussion
> with several code developers. The result is that we have decided to
> go with backslash as new separator for namespaces. The IRC log that
> illustrates why we in the end decided to go with changing the
> separator and the final decision on backslash can be found on the
> wiki [1].
>
> Greg is working on a patch, however Dmitry said he will assist even
> though he was actually opposed to the decision we made in the end. I
> very much appreciate Dmitry accepting this decision in such a
> professional manner.
>
> At the same time I hope that all people that have participated in
> this discussion accept this decision as one that was made by a
> sufficiently large subset of the development community. We did not
> take the decision lightly but we felt confident that this decision
> is for the best of PHP going forward.
>
> As the patch is still under development it is yet unclear how this
> will affect the scheduling PHP 5.3.
>
> regards,
> Lukas Kahwe Smith
> mls@pooteeweet.org
>
> [1] http://wiki.php.net/rfc/namespaceseparator
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Ilia Alshanetsky





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Marco
Re: [PHP-DEV] </endnamespacediscussion>
October 27, 2008 01:40PM
2008/10/27 Ilia Alshanetsky <[email protected]>

> 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
Andrei Zmievski
Re: [PHP-DEV] </endnamespacediscussion>
October 27, 2008 07:55PM
You're welcome.

Benjamin Schulz wrote:
> Thanks for another great argument to move away from PHP asap.
>
> On 25.10.2008, at 20:07, Lukas Kahwe Smith wrote:
>
>> that we have decided to go with backslash as new separator for
>> namespaces.
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login