Also it is faster and much better on memory consumption (depends on app of course, but 10-20% speedup and 20-30% less peak memory have been observed on some mainstream apps).
Yes, most probably you will see significant improvements. Of course, it depends on your app - if your app spends 99% of time in SQL database calls, PHP can do nothing about it. But PHP part would be faster and take less memory.
It’s been a feature request for at least eight years, it should never have arisen in the first place, and it should have been a one-line fix even if it had arisen. I don’t mean to knock PHP too badly; it’s quite useful, even if it is rather quirky. I just find it so unfortunate that this silly thing got so out of hand.
It's not "one liner", and couldn't be if you understand how PHP engine works. But it wasn't super-hard to implement, just nobody got to it till now.
It did not "get out of hand" by any measure. Once there was a consensus that this feature is needed by the significant part of PHP community, it was implemented. Could it be done earlier? Maybe, so could a lot of other nice things.
The www.php.net mirror will only be rsynced tomorrow, for now use http://docs.php.net/manual/en/migration54.php instead to get infos about 5.4 features. It's a good bit more up to date.
Really looking forward to traits. We have some hacks using interfaces and __call that we have been using to try and approximate traits, but the real thing is always much better. :)
Same here. This is a move away from inheritance to mixins. They did a stellar job with it and it's really flexible. Check out http://us2.php.net/traits for the nitty-gritty.
I've used traits a few times and in each case replaced it later by either inheritance or moving the functionality into separate classes. I'm not getting the design considerations that call for traits over alternatives. How would one use, and why is it the better option?
Main problem there is $foo→bar()() which seems to be harder to implement on top of existing parser.
Otherwise the patch is here: https://wiki.php.net/rfc/fcallfcall but since it's not complete it wasn't merged.
PHP was originally designed for simple, procedural bits of logic inside individual HTML pages. In that context, there's nothing wrong with the feature itself.
array dereferencing - $object->method()[$index] is now valid syntax
built-in webserver via CLI - php -s - http://php.net/manual/en/features.commandline.webserver.php
traits and the insteadof operator - http://php.net/language.oop5.traits.php
shortened array syntax - $array = [1, 2, [1, 2, 3], 4];
Finally removed register_globals ;)
Default charset of UTF-8!
Read all about it! http://www.php.net/manual/en/migration54.php