3 ms·

A lot of those changes look like good things taken from other languages that have done it well (the null ?-> and ??, ...). But many things seem to be quite of

A lot of those changes look like good things taken from other languages that have done it well (the null ?-> and ??, ...). But many things seem to be quite of a burden instead of a progress => why create a new match syntax when a switch is already well known for something similar? That will create confusion (thinking of all the for types of loops in JS!), plus it's still not an enum and cases will be missed. And the worst being the attribute #[] syntax... why?! Almost every other language uses @attribute, and it is successful: simple to write, easy to read, why on earth a new and such complicated solution? While php is making progress step by step, it has no chance of ever becoming of good reputation if it goes all the way to make itself more crazy.

lifthrasiir 6y ago
> And the worst being the attribute #[] syntax... why?! Almost every other language uses @attribute, and it is successful: simple to write, easy to read, why on earth a new and such complicated solution? Simple, it was already taken up [1]. Also `@attribute` syntax is by no way universal (and semantics wildly vary even with the same syntax): `#[]` in particular might have been inspired by Rust. [1] https://www.php.net/language.operators.errorcontrol https://www.php.net/language.operators.errorcontrol
- gregoriol 6y ago
  The rfcs have a lot of discussion on those subjects indeed, but I still disagree with the choice! Also, the current use of @ is before a function call or some get, not before a method/class/... declaration, so a change in that direction would probably be possible. (plus the @ to suppress errors should probably be removed from the language anyway!)
  - IluTov 6y ago
    It's not possible because PHP has a LALR(1) parser but this would require arbitrary lookahead.
deergomoo 6y ago
> And the worst being the attribute #[] syntax... why?! Hah. Since the initial RFC was agreed, I think there were three changes to the syntax because no-one could agree. At one point it was going to be `@@attribute`. #[] is similar to or the same as Rust, I believe. It also has the advantage of being backwards compatible; while rarely used, comments in PHP can start with # instead of //, so older versions of PHP will just see an attribute as a comment. Of course, that also means that a comment in old code might now be interpreted as an attribute, but there you go. Single @ is probably a no go because @ is already the error suppressing operator. Now, in my opinion that should be ejected from the language with extreme prejudice, but I doubt it ever will be.
- Supermancho 6y ago
  PHP laughably adds warts almost as fast as it removes them, then codifies the new ones as intentional. Hack was a good attempt, but I fear it's too late to fix the soup of features by forking/cloning. I sincerely believe another language will replace it (not python), if they havent already (javascript shudder). I've used PHP professionally for over 20 years along with other languages. The decisioning of language design, at large, has been mired in "good enough and doesn't break backward compatibility" nonsense all over the spectrum. PHP was the poster child of thinking differently in the 90s. Make the languages BETTER by looking at others, not clutching your Perls /s. Arcane sigils are not the way forward, that's a known (eg Erlang, Haskell, Pony, Perl, etc), even with powerful features that put existing languages to shame.

lifthrasiir 6y ago

> And the worst being the attribute #[] syntax... why?! Almost every other language uses @attribute, and it is successful: simple to write, easy to read, why on earth a new and such complicated solution? Simple, it was already taken up [1]. Also `@attribute` syntax is by no way universal (and semantics wildly vary even with the same syntax): `#[]` in particular might have been inspired by Rust. [1] https://www.php.net/language.operators.errorcontrol https://www.php.net/language.operators.errorcontrol

gregoriol 6y ago
The rfcs have a lot of discussion on those subjects indeed, but I still disagree with the choice! Also, the current use of @ is before a function call or some get, not before a method/class/... declaration, so a change in that direction would probably be possible. (plus the @ to suppress errors should probably be removed from the language anyway!)
- IluTov 6y ago
  It's not possible because PHP has a LALR(1) parser but this would require arbitrary lookahead.

deergomoo 6y ago

> And the worst being the attribute #[] syntax... why?! Hah. Since the initial RFC was agreed, I think there were three changes to the syntax because no-one could agree. At one point it was going to be `@@attribute`. #[] is similar to or the same as Rust, I believe. It also has the advantage of being backwards compatible; while rarely used, comments in PHP can start with # instead of //, so older versions of PHP will just see an attribute as a comment. Of course, that also means that a comment in old code might now be interpreted as an attribute, but there you go. Single @ is probably a no go because @ is already the error suppressing operator. Now, in my opinion that should be ejected from the language with extreme prejudice, but I doubt it ever will be.

Supermancho 6y ago
PHP laughably adds warts almost as fast as it removes them, then codifies the new ones as intentional. Hack was a good attempt, but I fear it's too late to fix the soup of features by forking/cloning. I sincerely believe another language will replace it (not python), if they havent already (javascript shudder). I've used PHP professionally for over 20 years along with other languages. The decisioning of language design, at large, has been mired in "good enough and doesn't break backward compatibility" nonsense all over the spectrum. PHP was the poster child of thinking differently in the 90s. Make the languages BETTER by looking at others, not clutching your Perls /s. Arcane sigils are not the way forward, that's a known (eg Erlang, Haskell, Pony, Perl, etc), even with powerful features that put existing languages to shame.