PHP: \ as namespace separator. What were they thinking? | Hacker News Reader

PHP: \ as namespace separator. What were they thinking?

ninh.nl

37 pointsSujan26 comments

If past PHP trends are any indication..

PHP 6: "\" is an awesome new feature that makes web development more approachable.

PHP 7: "\" is an awful idea, avoided by the clueful and widely denounced. You can disable it in php.ini, but that's not the default. 80% of practicing developers know none of this.

PHP 8: The php.ini default changes. Gang wars erupt in the shared hosting ghetto. You can force it on or off at the code level, and a comment thread in the PHP manual contains 23 different slightly-broken copy-and-paste snippets.

PHP 9: "\" doesn't exist anymore. Everyone ignores PHP 9 until three weeks before PHP 8 is EOL'd.

Magic quotes... [shudder]

register_globals... [shudder x 2]

safe_mode... [shudder x 3]

PHP 15: PHP 6 finally available in most shared-hosting environments; 95% of developers first read of "\" abortion (errr, awesome new feature)

This decision, and all the crap surrounding it - the decision making process, the reasons given for deciding on '\', etc - sum up very well why I do not like working with PHP.

It's not that I can't get stuff done with it. It's that it is designed and maintained by people who don't know very much about language design, coupled with the fact that PHP is in position to have some people that are experienced with such things come in and re-do it.

I mean, I'm far from being versed in the ways of writing programming languages, but I can write a parser that can handle one token being used for different things if I need to. I would think that it's a pretty common thing (and is probably in the class of things where you'd rarely be writing one from scratch, but I digress).

Every time I use it, I end up feeling like I'm beating my face against the language. That's not quite accurate - I end up feeling like I'm beating my face against years of poorly thought out design decisions with little to no effort made to remove them.

Perhaps I'm missing out on some things that make this a lot harder for PHP, especially considering that I'm not part of the PHP community (and considering that I avoid it when possible) - but it really seems to me that most of PHPs problems, from a language perspective, are solved problems.

More links:

- http://wiki.php.net/rfc/namespaceseparator

- http://news.php.net/php.internals/41374

- http://loveandtheft.org/2008/10/26/set-sail-for-fail-php-nam...

One more: http://scriptnode.com/article/php-to-use-backslash-as-namesp...

One more: http://phpimpact.wordpress.com/2008/10/28/php-namespaces-con...

They should have stuck with Paamayim Nekudotayim for the namespace and either 1) returned an error for ambiguities or 2) used some prefix for namespaces like !Foo::bar().

1) is less desirable because unlike C++ PHP is not compiled. I could imagine some random included file that you disabled for testing causing an ambiguity error.

2) could work if you choose a representation that is human readable and easily parsable. The exclamation point seems to fit that description.

Lets say bar() returns false. Are the following two lines the same?

    true == !false
    true == !Foo::bar()

Paamayim Nekudotayim is the best option, you could even use it as a prefix in case of ambiguity:

    true == ::Foo::bar()

Easily solved by using '!!' instead of '!'. But it doesn't matter to me. I like to complain about PHP while using it, and I get a lot of stuff done in PHP, but I don't really care about it.

You can chain !, so "true == !! true" is true.

You can, but I can't think of any reason to do so, which is why I mentioned it.

generated code

to convert stuff to explicit true/false

> generated code

Not a problem: either the PHP generated is only safe for a particular version, or they can add parenthesis to distinguish the cases.

> to convert stuff to explicit true/false

I suppose. That would seem like a surprising use to me, and would merit an explanatory comment, but given that, it might be better to just explicitly cast ("(bool)$name"), which saves the comment, and only adds four characters over "!!$name".

Every syntax quirk that requires the code generator to do something (e.g. add more parentheses) makes code generation harder.

I would naively expect every single expression to be surrounded by parenthesis by default, implemented in the lowest level writeExpression() function or whatever. But I've never written a translator, so...

Which of these would be the same?

   !(!(true))
   ! ! true
   !!true

Having !! not be the same as ! ! would probably be the first case in PHP of significant whitespace.

I would assume that the first would be different than the second two, in the case that !! was some other operator. It's not clear to me whether other cases in which there are double-character operators tolerate having whitespace between them. Is "$name++" the same as "$name+ +", or is the latter an error, or neither? I can't be bothered to check right now. :)

That all depends on whether or not PHP considers true == true. Knowing =='s track record... it wouldn't surprise me if it didn't :)

Choose some other prefix then as long as we can use Paamayim Nekudotayim for namespaces :)

Last one looks fine to me.

What php does now make me have no confidence in its future. Already started a transformation for exist website from php to python. Like what Paamayim Nekudotayim said, these guys who develop php interpreter have limited vision from the global language development. Thus, it time to leave php behind.

Who cares? They explained why this was the least-bad option, and the provided rationale make sense. Yes, if they had not made so many bad choices over the years, they wouldn't be here, but they did, so they are.

You shouldn't be using PHP anyway, it's a toy for kids.

I also really still like Lego, so well, that's not an argument :P

Reply on news.ycombinator.com