The new proposed namespace separator "\" is disgusting

[emehrkay]

http://ninh.nl/blog/2008/10/25/a-word-on-phps-upcoming-namespace-seperator/

 

The PHP developers feel that it is impossible for them to use the double colon as a namespace separator, so their proposal is to use the backslash

 

namespace Example:

function func(){}

Example\func(); 
//instead of
Example::func();

 

What do you think?

[corbin]

I concur.  That's disgusting.

 

 

 

 

 

They could use like....

 

 

Example.func();

 

(Since . isn't used with classes in PHP.)

 

 

Or hrmm what else could they use....

 

Example|func();

(Ugly but better than \.)

 

Example:func();

Example~func();

 

 

Anything would be better than \.  Wth?

[Daniel0]

They could use like....

 

 

Example.func();

 

define('Example', 'foo');

function func() {
    return 'bar';
}

 

namespace Example;

function func() {
    return 'Hello World';
}

 

Now what will the returned value be when evaluating Example.func()?

[emehrkay]

I think that they should just use the double colon. They'd have to make classnames/namespaces case sensitive, but that is a small thing. Hell of a lot better than Example\foo(); Who calls classes outside of the defined case anyway?

[corbin]

They could use like....

 

 

Example.func();

 

define('Example', 'foo');

function func() {
    return 'bar';
}

 

namespace Example;

function func() {
    return 'Hello World';
}

 

Now what will the returned value be when evaluating Example.func()?

 

 

Touché.

 

 

I thought about string concatenation, but I thought "Well, it wouldn't be variables, so it wouldn't matter."

 

I somehow managed to forget about constants lol.

[KevinM1]

In a perfect world, PHP would do one of two things:

 

1. Overload the :: operator to work with namespaces.

2. Overload the + operator to concatenate strings, so . could be used in conjunction with namespaces.

 

Option 1 would be ideal, but I wouldn't mind option 2.  I always hated using . for string concatenation.  The operator itself has no semantic value. 

 

Of course, option 2 is out, given the cost and pain it would take to modify scripts to take into account the potential new operator.  Unfortunately.  Because I really, really hate using . with strings.

[.josh]

foo>>bar

 

I win.

[Daniel0]

1. Overload the :: operator to work with namespaces.

 

You obviously don't understand the problem. You risk ambiguity by doing that.

 

2. Overload the + operator to concatenate strings, so . could be used in conjunction with namespaces.

 

Again, ambiguity. Does '5' + 10 evaluate to int 15 or to string '510'? It's just not possible to overload the + operator to work with string concatenation in PHP as well.

[KevinM1]

1. Overload the :: operator to work with namespaces.

 

You obviously don't understand the problem. You risk ambiguity by doing that.

 

Does it really matter, though?  You're either accessing something statically through a class or through a namespace.  I fail to see why that would matter.

 

2. Overload the + operator to concatenate strings, so . could be used in conjunction with namespaces.

 

Again, ambiguity. Does '5' + 10 evaluate to int 15 or to string '510'? It's just not possible to overload the + operator to work with string concatenation in PHP as well.

 

Other languages (JavaScript and C# of the top of my head) handle it just fine.  There just needs to be a consistent result in cases like that, regardless of what it actually is.  So, it wouldn't matter if your case yielded the number 15 or the string 510, so long as it, and all other similar cases, behaved the same way.

 

It's possible, it's just that it's slightly messy because it would require a cast to be thrown in a lot of cases, one way or the other.  I can live with that.

[Daniel0]

Did you read the post emehrkay linked to?

 

[...] consider the following PHP code example utilizing namespaces:

namespace Foo;
function bar() {
    echo "Namespace Foo";
}

With this code, we can invoke the bar function in the namespace Foo in the following way:

Foo::bar();

Now lets take a look at how we invoke static class members in PHP:

class Foo {
    static function bar() {
        echo "Class Foo";
    }
}

We can invoke the static bar function in the class Foo the following way:

Foo::bar();

U-oh…. I’m pretty sure we saw this before! Indeed, this line of code is identical to that of invoking a function bar in the namespace Foo. It seems we’ve stumbled across an ambiguous method invocation that the interpreter is unable to resolve in this case.

 

There is clearly a problem here...

 

Other languages (JavaScript and C# of the top of my head) handle [overloading the + operator] just fine.  There just needs to be a consistent result in cases like that, regardless of what it actually is.  So, it wouldn't matter if your case yielded the number 15 or the string 510, so long as it, and all other similar cases, behaved the same way.

 

It's possible, it's just that it's slightly messy because it would require a cast to be thrown in a lot of cases, one way or the other.  I can live with that.

 

It's still an incredibly stupid idea. It'll completely break all previous scripts and 5.3 is only a minor milestone! It has taken people forever to upgrade to PHP 5 and it introduced far less compatibility issues than doing that would. How long time do you then think it'll take people to adopt 5.3 or indeed 6.0 when it's eventually due? Besides, C# is not dynamically typed, so it cannot be used as an example here. Javascript will just always make it a string and that's fine because it has always done that.

[KevinM1]

Did you read the post emehrkay linked to?

 

[...] consider the following PHP code example utilizing namespaces:

namespace Foo;
function bar() {
    echo "Namespace Foo";
}

With this code, we can invoke the bar function in the namespace Foo in the following way:

Foo::bar();

Now lets take a look at how we invoke static class members in PHP:

class Foo {
    static function bar() {
        echo "Class Foo";
    }
}

We can invoke the static bar function in the class Foo the following way:

Foo::bar();

U-oh…. I’m pretty sure we saw this before! Indeed, this line of code is identical to that of invoking a function bar in the namespace Foo. It seems we’ve stumbled across an ambiguous method invocation that the interpreter is unable to resolve in this case.

 

There is clearly a problem here...

 

Which is where namespace assignment comes into play, with a little help from the global namespace in helping us:

 

namespace Foo
{
   function bar()
   {
      echo "namespace Foo";
   }
}

$myNamespace = global::Foo; //to steal an idea from C#

class Foo
{
   public static function bar()
   {
      echo "class Foo";
   }
}

$myNamespace::bar();
Foo::bar();

 

To put it another way, other languages implement namespaces using the scope resolution operator.  I fail to see why PHP cannot do the same.  It all comes down to how Zend wants to overload their existing language constructs. 

 

Other languages (JavaScript and C# of the top of my head) handle [overloading the + operator] just fine.  There just needs to be a consistent result in cases like that, regardless of what it actually is.  So, it wouldn't matter if your case yielded the number 15 or the string 510, so long as it, and all other similar cases, behaved the same way.

 

It's possible, it's just that it's slightly messy because it would require a cast to be thrown in a lot of cases, one way or the other.  I can live with that.

 

It's still an incredibly stupid idea. It'll completely break all previous scripts and 5.3 is only a minor milestone! It has taken people forever to upgrade to PHP 5 and it introduced far less compatibility issues than doing that would. How long time do you then think it'll take people to adopt 5.3 or indeed 6.0 when it's eventually due? Besides, C# is not dynamically typed, so it cannot be used as an example here. Javascript will just always make it a string and that's fine because it has always done that.

 

Oh, I understand that the logistics of making such a change would be a nightmare.  The . operator seems like something PHP stole from Perl, before the decision was made to implement OOP.  PHP has worked around it to an extent, using what is typically a pointer dereferencing operator as its standard object-member operator.  I think that shows some shortsightedness on Zend's part.  A move to a more standard syntax could have helped eliminate the issue we're talking about here.  Such a move would have been infinitely more possible between versions 3 and 4 rather than now.  Unfortunately, like you say, such a change would be impossible at present.

[corbin]

foo>>bar

 

I win.

 

That would make me feel like I were piping it.  lol.  Does kick \'s ass though.

 

 

 

$myNamespace = global::Foo; //to steal an idea from C#

 

 

Ewwwwww....  I wouldn't want to ever do that.

[DarkWater]

>> is the bitwise right shift operator, so that could cause some potential problems (although bitshifting by a string wouldn't really doing anything...).

[Stooney]

I've never worked with namespaces before so anything will be just as awkward to me.  I do agree it's ugly though.  Nonetheless, whatever the final decision is people will get used to it and forget about it.  If Bush can stay in power as long as he has then \ can make it to production.

[DarkWater]

Yeah, but nobody likes Bush and they all make fun of him around the water cooler.  Even Condoleeza.  I don't think that the backslash can tolerate that kind of backtalk.

[corbin]

>> is the bitwise right shift operator, so that could cause some potential problems (although bitshifting by a string wouldn't really doing anything...).

 

define('foo', 1);

namespace foo {
    function bar() {
        return 5;
    }
}

echo foo>>bar();

 

 

 

>.<

 

 

 

I didn't even think of bitwise stuff before you said that though....

[aximbigfan]

OH PLEASE NOOOO!!!!!!!

 

Use \ when you are escaping something. No where else.

 

EDIT: Mod can we maybe add a poll?

 

Chris

[trq]

Am I missing something here.

 

foo.php

<?php

namespace foo;

class a {

    public static function b() {
echo "here is foo::a::b\n";
    }
}

foo.a.php

<?php

namespace foo::a;

class x {

    public static function y() {
echo "here is foo::a::x::y\n";
    }
}

test.php

#!/usr/local/bin/php
<?php

include 'foo.php';
include 'foo.a.php';

foo::a::b();
foo::a::x::y();

?>

 

Results in (PHP 5.3.0alpha2-dev (cli))....

here is foo::a::b
here is foo::a::x::y

 

Is there a problem?

[DarkWater]

foo.php

namespace Foo;
function test() { echo 'good'; }

include('foo.php');
class Foo {
    public static function test() { echo 'good'; }
}

Foo::test();

 

I think.  Try that.

[trq]

I suppose, but having any class within the global namespace that is named the same as a defined namespace is going to cause trouble.

 

Maybe I'm still missing the point?

[DarkWater]

I suppose, but having any class within the global namespace that is named the same as a defined namespace is going to cause trouble.

 

Maybe I'm still missing the point?

 

I mean, I completely agree that you shouldn't define global namespace classes with the same name as a namespace, but think about all the PHP programmers who, sadly, have absolutely no experience and still try to write code (which seems to be like 90% of them these days). >_<

[dropfaith]

I mean, I completely agree that you shouldn't define global namespace classes with the same name as a namespace, but think about all the PHP programmers who, sadly, have absolutely no experience and still try to write code (which seems to be like 90% of them these days). >_<

 

i just always find it amusing that you have more experience then a lot of programmers and your 15.

if only i started that young instead of being a stupid teenager like i was i would be alot farther in life

 

[corbin]

I'm a stupid teenager and a PHP guy.

 

 

 

Wooo multitasking!

[Daniel0]

Wooo multitasking!

 

Booo multitasking!

[DarkWater]

I mean, I completely agree that you shouldn't define global namespace classes with the same name as a namespace, but think about all the PHP programmers who, sadly, have absolutely no experience and still try to write code (which seems to be like 90% of them these days). >_<

 

i just always find it amusing that you have more experience then a lot of programmers and your 15.

if only i started that young instead of being a stupid teenager like i was i would be alot farther in life

 

Funny thing is that I'm still a stupid teenager.  I've done my share of stupid shit already at parties and out with friends; I just program because I can and it's interesting.