3 ms·
The core team has it's own priorities, and has a history of ignoring the requests of the dev community. A couple of examples: in version 5.3, they added `goto`.
by jessedhillon 15y ago
The core team has it's own priorities, and has a history of ignoring the requests of the dev community. A couple of examples: in version 5.3, they added `goto`. WTF. Who, after five major releases, decides that what a language really needs is `goto`.
In the same release, they decided to finally add namespaces. But, despite the tired claim that PHP takes cues from C/C++/Java, they did not reuse :: (aka paamayim nekudotayim) as the scope resolution operator. Instead, they devised a new operator: '\'.
There is an IRC log somewhere where you can read the painful arguments back and forth over what this operator should have been. One of the rationalizations for the backslash was that it makes sense to Windows developers, as they are already familiar with the idea of '\' being used to separate elements of a hierarchy.
The end result:
Java:
Attribute/Method access: foo.bar
Static method access: Foo.bar
Package access: foo.bar.baz
C#:
Attribute/Method access: foo.bar
Static method access: Foo.bar
Namespace access: foo.bar.baz
Python:
Attribute/Method access: foo.bar
Static method access: Foo.bar
Module access: foo.bar.baz
PHP:
Attribute/Method access: $foo->bar
Static method access: Foo::bar
Namespace access: foo\bar\baz
- wvenable 15y agoNone of these languages except for PHP have their own string concatenation operator. They overload + for that purpose. They're also all strong typed languages while PHP is weakly typed. Overloading + for string concatenation in a weakly typed language is a recipe for disaster (see JavaScript). > Who, after five major releases, decides that what a language really needs is `goto`. It makes it a much easier compilation target. > But, despite the tired claim that PHP takes cues from C/C++/Java, they did not reuse :: They couldn't because unlike C/C++/Java the entire project isn't compiled at once. At compile time, PHP has no idea that the symbol preceding the operator is a class name or namespace from one run to the next. It might have been possible to resolve that with major changes to the underlying engine or maybe not. I absolutely hated the idea of the backslash when proposed but after using it for a while it seems fairly comfortable.
- jessedhillon 15y agoI know that there are reasons for this behavior. None of them are good, however. Why couldn't they reuse the same resolution operator for all three, even if it's not the period character? Looking at your responses all over this post, there is a big disconnect. Other people -- who probably use and enjoy other languages -- raise issues with PHP that point at poor design. Then you respond with a rationale for why the well-designed thing couldn't be done. (Or, why the poorly-designed thing was done.) But all designs have rationales. The point is that the people who make design decisions for PHP choose poorly. Even if you give us the rationale, that doesn't make it a good decision in retrospect. Also, could you explain this statement please: > It makes it a much easier compilation target. Do you mean that other languages can be compiled to PHP more easily? Because I have never heard this rationalization before.
- wvenable 15y ago> Why couldn't they reuse the same resolution operator for all three, even if it's not the period character? It may have been possible to do that when the language was originally designed but PHP has taking the long road to getting real OOP. PHP3 had objects but no inheritance; they were really just structs with functions. PHP4 added a lot more ability but, for reasons of compatibility, left a few things unchanged that should have been changed. PHP5 fixed most of those remaining issues and continues to add more features with every release. PHP wasn't designed all at once and things were added as developers demanded them. It was just supposed to be a procedural languages like ASP/VBScript but as a mix of C and Perl; all this object oriented stuff wasn't in the original plan. It now has namespaces and exceptions and all kinds of things that nobody imagined it would ever have. So they can't use one operator for all because each operation compiles down to something different (each from a different time) and that difference needs to be known at compile time without the benefit of knowing what the symbols resolve to. > Other people -- who probably use and enjoy other languages -- raise issues with PHP that point at poor design. This is a poor argument. I use and enjoy many other languages. In fact, I'm hardly doing any PHP development right now but I've got half-completed side project I'd like to finish. There's no argument: PHP has a poor design. But if you put things in the context of history, there is reason for that poor design. > Then you respond with a rationale for why the well-designed thing couldn't be done. I'm just stating the facts. In this case, it's not like they're going out of the way to be difficult but they have to work with what they have. If you have a time machine we could solve this once and for all. > that doesn't make it a good decision in retrospect. Of course, but hindsight is always 20/20. Perhaps Python should have had unicode to start with and should have never made print a statement instead of a function. Perhaps templates were not the best way to add generics to C++. See, we can play this game all night. > Do you mean that other languages can be compiled to PHP more easily? Because I have never heard this rationalization before. Yes. That rationalization was one of the reasons for adding it although more in the context of targeting parser generators (like lexx and yacc) to PHP. Even Dijkstra didn't think that goto should been banished from all languages forever.