4 ms·

PHP is Open Source. Compiling a list like this is nice, but contributing something back, and getting involved in making improvements to PHP, would be nicer.

code_duck 15y ago
Raising awareness of what needs to be fixed is the first step.
- EamonLeonard 15y ago
  Agreed, but if you're going to put the energy into picking out what doesn't work, you probably have spent time thinking about how it should be done, so following through is worthwhile for all concerned.
dexen 15y ago
There's an outstanding request for better array syntax. It's been out there for over 3 years and received a lot of support from the community. At least one implementation has been submitted. But the core dev team rejected the idea, as they are convinced having second syntax available would harm ease of use (and thus popularity) of the language. In general, some aspects of PHP will not be fixed/improved for reasons of either: * backward compatibility, or * incompatibility with the vision of the language by the core dev team. http://marc.info/?t=121142259100001&r=1&w=2 http://marc.info/?t=121142259100001&r=1&w=2 http://marc.info/?t=119995974300003&r=1&w=2 http://marc.info/?t=119995974300003&r=1&w=2
- EamonLeonard 15y ago
  Indeed, one of the downsides of Open Source... politics etc, it doesn't help, but tends to come with the territory.
- philolson 15y ago
  This is being revisited as per the PHP 5.4 TODO. My guess is it'll happen this time around, and I voted against it previously (but changed said vote). https://wiki.php.net/todo/php54 https://wiki.php.net/todo/php54
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 ago
  None 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 ago
    I 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.
zokier 15y ago
Many flaws in PHP are unfixable without breaking compatibility, and if you break compatibility you lose the only advantage that PHP has these days.

code_duck 15y ago

Raising awareness of what needs to be fixed is the first step.

EamonLeonard 15y ago
Agreed, but if you're going to put the energy into picking out what doesn't work, you probably have spent time thinking about how it should be done, so following through is worthwhile for all concerned.

dexen 15y ago

There's an outstanding request for better array syntax. It's been out there for over 3 years and received a lot of support from the community. At least one implementation has been submitted. But the core dev team rejected the idea, as they are convinced having second syntax available would harm ease of use (and thus popularity) of the language. In general, some aspects of PHP will not be fixed/improved for reasons of either: * backward compatibility, or * incompatibility with the vision of the language by the core dev team. http://marc.info/?t=121142259100001&r=1&w=2 http://marc.info/?t=121142259100001&r=1&w=2 http://marc.info/?t=119995974300003&r=1&w=2 http://marc.info/?t=119995974300003&r=1&w=2

EamonLeonard 15y ago
Indeed, one of the downsides of Open Source... politics etc, it doesn't help, but tends to come with the territory.
philolson 15y ago
This is being revisited as per the PHP 5.4 TODO. My guess is it'll happen this time around, and I voted against it previously (but changed said vote). https://wiki.php.net/todo/php54 https://wiki.php.net/todo/php54

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 ago
None 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 ago
  I 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.

zokier 15y ago

Many flaws in PHP are unfixable without breaking compatibility, and if you break compatibility you lose the only advantage that PHP has these days.