11 ms·

While you're right, in theory, it would take a complete change of PHP's semantics to pull that off. PHP adopted Java's static class model, even though it makes

by troels 17y ago

While you're right, in theory, it would take a complete change of PHP's semantics to pull that off. PHP adopted Java's static class model, even though it makes little sense in a dynamically typed, interpreted language. There are a few upsides to that (Less meta programming makes it easier to understand programs), but the downside is a rather inconsistent language.

wvenable 17y ago
Why would it take a complete change of PHP's semantics? Accessing static members of classes follow C++ syntax, there's no reason why namespaces couldn't follow the same syntax and semantics. It would break nothing in the PHP language spec. namespace foo1; function bar(); class foo2 { function bar(); } foo1::bar(); // Namespace call foo2::bar(); // Static method call namespace foo2; // Syntax error; class foo2 already exists. The problem is, the internals of PHP are that namespaces and classes are in different hashes and the call to either compile to entirely different byte code. The "correct" implementation would have namespaces and classes together and both calls compile to the same code. Now I accept that the PHP internals are perhaps too convoluted to resolve this issue but that doesn't make this any less terrible. It's a hack solution.
- encoderer 17y ago
  Ok, i'll bite... why does it matter? Why on Earth does it matter? What could you do better with the scope-resolution operator?
  - mikeryan 17y ago
    I'd upmod you more if I could...
  - wvenable 17y ago
    Death by a million cuts. The scope-resolution operator doesn't matter. The weird scoping rules aren't so bad. The inconsistent function parameters are really no big deal. What's one more mis-feature right? I was really hoping that PHP was going to grow up and shed some its moronic nature but this is yet another half-ass solution.
    - encoderer 17y ago
      The fact is that as much as everyone likes to complain about parameter order, the only case I've seen with the needle/haystack order flipped is the in_array() method, which in that context the flipped order just makes sense. And I'm not sure what you mean by "weird scoping." The real beef most people have with PHP -- and is hard to defend -- is its type coercion. But PHP is not alone here, any implicit coercions are bound to make somebody unhappy some of the time. In summary, you're jumping on a bandwagon without any merit. Say that you can make better applications and in less time in another language. Say that you can find more talented programmers for less money. But of all the things to whine about you chose the namespace operator? Really?
      - wvenable 17y ago
        You completely missed the point. Yes, you can defend all those things individually. And individually, they aren't a big deal. But together PHP seems like a big ball of mud. I'm actually a big user (and defender) of PHP; between posting this I'm working on PHP code. I've used it since PHP 3.0 and I'm pretty forgiving of legacy problems -- it's an organic language with pieces added when they're needed. The PHP 3.0 time was great because every release (which was frequent) brought some new feature you were wishing for. PHP 5.0 has been great and PHP 6.0 with unicode is going to be a nice addition too. But it's like 2 steps forward and 1 step back. There's no reason for PHP to add namespaces in such a confusing and different way. PHP borrows from C, Java, Perl, and C++ and anyone familiar with those languages is going to feel comfortable with it. But this namespace implementation is just bizarre. And it can't be blamed on any legacy issues or backwards compatibility.
        encoderer 17y ago
        I'd like to dial this back a bit. But not without saying that knocking down strawmen is not "defending things individually." And really... you find it "confusing and different" that PHP uses a backslash for delimitation? Seriously? You can simultaneously wrap your mind around recursion, closures, pointer arithmetic and continuations but you're confused by the use of a backslash opposed to a colon, double-colon or triple colon? Confusing and Different? Seriously? Variety is unambiguously good. This is mutation and evolution. And it results in languages as fantastically different as Haskell, C, F#, Python, Perl, Lisp and even PHP. Programmers are by and large a smart bunch and the last thing we need to do is dumb-down languages for the least common denominator.
- KrisJordan 17y ago
  Here is an example of an ambiguous case: // classes.php ///// namespace foo::bar; function baz() {} namespace foo; class bar { static function baz() {} } // someotherfile.php ///// include('classes.php'); foo::bar::baz(); // Ambiguity ///// A proposed work around for the ambiguity was being explicit about ambiguous cases. The internals team wanted to do ::, they did ::, and they convinced themselves otherwise (and suffered through a lot of pain in the process). [17:00:05] <@CelloG> I am the strongest advocate for :: - every patch I have made up to this one was designed to preserve it, and I am convinced it just isn't technically possible to use it http://wiki.php.net/rfc/backslashnamespaces#resolution_of_t_string_t_paamayim_nekudotayim_t_string_and_why_this_kills_as_namespace_separator http://wiki.php.net/rfc/backslashnamespaces#resolution_of_t_...
  - wvenable 17y ago
    I've read that link and I understand it. They treat namespace access and static class access as different things. If they were the same, and namespaces and classes shared the same hash, and static class access and namespace access where the same (like in C++) this would be a non-issue. As for your ambiguity, it's a simple name clash. On the second declaration, you should get an error because foo::bar is already defined. You know, like you would in C++.
    - encoderer 17y ago
      Ahhh, I gotcha... Honestly, I hope you can put your pride aside for a moment and think about this. Under your scheme, if you were to create a namespace foo, you couldn't have a class named foo in any namespace in your application.
      - wvenable 17y ago
        Ummm, no. In C++, classes are looked up the same as namespaces, you can have a namespace called foo::foo::foo::foo which contains a class called foo! The only restriction is that you can't have a class or namespace with the exact same fully qualified name. That's a perfectly reasonable restriction. The whole purpose of namespaces is so you can have a class called foo in a different namespace from another class called foo.

by troels 17y ago

wvenable 17y ago

Why would it take a complete change of PHP's semantics? Accessing static members of classes follow C++ syntax, there's no reason why namespaces couldn't follow the same syntax and semantics. It would break nothing in the PHP language spec. namespace foo1; function bar(); class foo2 { function bar(); } foo1::bar(); // Namespace call foo2::bar(); // Static method call namespace foo2; // Syntax error; class foo2 already exists. The problem is, the internals of PHP are that namespaces and classes are in different hashes and the call to either compile to entirely different byte code. The "correct" implementation would have namespaces and classes together and both calls compile to the same code. Now I accept that the PHP internals are perhaps too convoluted to resolve this issue but that doesn't make this any less terrible. It's a hack solution.

encoderer 17y ago
Ok, i'll bite... why does it matter? Why on Earth does it matter? What could you do better with the scope-resolution operator?
- mikeryan 17y ago
  I'd upmod you more if I could...
- wvenable 17y ago
  Death by a million cuts. The scope-resolution operator doesn't matter. The weird scoping rules aren't so bad. The inconsistent function parameters are really no big deal. What's one more mis-feature right? I was really hoping that PHP was going to grow up and shed some its moronic nature but this is yet another half-ass solution.
  - encoderer 17y ago
    The fact is that as much as everyone likes to complain about parameter order, the only case I've seen with the needle/haystack order flipped is the in_array() method, which in that context the flipped order just makes sense. And I'm not sure what you mean by "weird scoping." The real beef most people have with PHP -- and is hard to defend -- is its type coercion. But PHP is not alone here, any implicit coercions are bound to make somebody unhappy some of the time. In summary, you're jumping on a bandwagon without any merit. Say that you can make better applications and in less time in another language. Say that you can find more talented programmers for less money. But of all the things to whine about you chose the namespace operator? Really?
    - wvenable 17y ago
      You completely missed the point. Yes, you can defend all those things individually. And individually, they aren't a big deal. But together PHP seems like a big ball of mud. I'm actually a big user (and defender) of PHP; between posting this I'm working on PHP code. I've used it since PHP 3.0 and I'm pretty forgiving of legacy problems -- it's an organic language with pieces added when they're needed. The PHP 3.0 time was great because every release (which was frequent) brought some new feature you were wishing for. PHP 5.0 has been great and PHP 6.0 with unicode is going to be a nice addition too. But it's like 2 steps forward and 1 step back. There's no reason for PHP to add namespaces in such a confusing and different way. PHP borrows from C, Java, Perl, and C++ and anyone familiar with those languages is going to feel comfortable with it. But this namespace implementation is just bizarre. And it can't be blamed on any legacy issues or backwards compatibility.
      - encoderer 17y ago
        I'd like to dial this back a bit. But not without saying that knocking down strawmen is not "defending things individually." And really... you find it "confusing and different" that PHP uses a backslash for delimitation? Seriously? You can simultaneously wrap your mind around recursion, closures, pointer arithmetic and continuations but you're confused by the use of a backslash opposed to a colon, double-colon or triple colon? Confusing and Different? Seriously? Variety is unambiguously good. This is mutation and evolution. And it results in languages as fantastically different as Haskell, C, F#, Python, Perl, Lisp and even PHP. Programmers are by and large a smart bunch and the last thing we need to do is dumb-down languages for the least common denominator.
KrisJordan 17y ago
Here is an example of an ambiguous case: // classes.php ///// namespace foo::bar; function baz() {} namespace foo; class bar { static function baz() {} } // someotherfile.php ///// include('classes.php'); foo::bar::baz(); // Ambiguity ///// A proposed work around for the ambiguity was being explicit about ambiguous cases. The internals team wanted to do ::, they did ::, and they convinced themselves otherwise (and suffered through a lot of pain in the process). [17:00:05] <@CelloG> I am the strongest advocate for :: - every patch I have made up to this one was designed to preserve it, and I am convinced it just isn't technically possible to use it http://wiki.php.net/rfc/backslashnamespaces#resolution_of_t_string_t_paamayim_nekudotayim_t_string_and_why_this_kills_as_namespace_separator http://wiki.php.net/rfc/backslashnamespaces#resolution_of_t_...
- wvenable 17y ago
  I've read that link and I understand it. They treat namespace access and static class access as different things. If they were the same, and namespaces and classes shared the same hash, and static class access and namespace access where the same (like in C++) this would be a non-issue. As for your ambiguity, it's a simple name clash. On the second declaration, you should get an error because foo::bar is already defined. You know, like you would in C++.
  - encoderer 17y ago
    Ahhh, I gotcha... Honestly, I hope you can put your pride aside for a moment and think about this. Under your scheme, if you were to create a namespace foo, you couldn't have a class named foo in any namespace in your application.
    - wvenable 17y ago
      Ummm, no. In C++, classes are looked up the same as namespaces, you can have a namespace called foo::foo::foo::foo which contains a class called foo! The only restriction is that you can't have a class or namespace with the exact same fully qualified name. That's a perfectly reasonable restriction. The whole purpose of namespaces is so you can have a class called foo in a different namespace from another class called foo.