[sipefree]

It's been a long time since I had any interest at all in PHP, and these new features make me feel uneasy once again.

The development server seems like the only good thing about it.

Traits looks like a silly implementation of multiple inheritance mixins, with a 'use' keyword that doesn't really fit in with the language itself. And the whole 'insteadof' thing looks weird. It will lead to hackish code for many people, encouraging weird monkey-patching.

The author says "when stored in an array", then proceeds to use "$functions['anonymous']". That's not an array. Sigh. I know PHP likes to call them that, but I just find it weird that they would continue to insist on mis-naming two of the fundamental data types of computer science.

The introduction of closures can only be a good thing, and a lot better than the passing of a string name of a function as a callback argument from before.

As usual though, it's expected that most servers and frameworks won't get the update for some time, due to whatever backwards incompatible changes have been made.

I know it's all the rage to hate on PHP these days, but even giving an objective look at the state of the language, given the thriving ecosystems of its competitors, makes it look to me like something I would never touch.

[j_col]

I don't think that PHP referring to hash maps as an array is a bad thing, in fact I've always loved the flexibility of the overloaded array implementation in PHP.

> ...due to whatever backwards incompatible changes have been made.

PHP is normally very good that way, does anyone know of any backwards incompatible changes that have been made?

> I know it's all the rage to hate on PHP these days, but even giving an objective look at the state of the language, given the thriving ecosystems of its competitors, makes it look to me like something I would never touch.

Yes you're right, it is quite fashionable to hate PHP and has been so for the ~10 years I've been using it, but who cares it gets the job done (a language for the pragmatists not the purists).

[sipefree]

> I don't think that PHP referring to hash maps as an array is a bad thing, in fact I've always loved the flexibility of the overloaded array implementation in PHP.

But they're not arrays. JavaScript and Lua do the same thing, allowing you to assign numeric or hashed keys on objects (or tables in Lua), but they don't call them Arrays, because they aren't. Arrays have expected behavior and implementations. So do hash maps. It's fine to amalgamate them, just give it the right name.

> PHP is normally very good that way, does anyone know of any backwards incompatible changes that have been made?

I haven't looked at any in this version, but recently there was an article (I think on HN) complaining about severe ABI changes that required all compiled modules to be recompiled, leading to adoption problems.

> Yes you're right, it is quite fashionable to hate PHP and has been so for the ~10 years I've been using it, but who cares it gets the job done (a language for the pragmatists not the purists).

I used PHP for many years as well, and for that reason I don't think it's a language for the pragmatist at all. It's not expressive enough, it encourages bad coding, and it doesn't have an ecosystem comparable to Ruby, Python, or even the amazing one Node.JS has managed to garner in the past year or so.

[randallsquared]

But they're not arrays. JavaScript and Lua do the same thing, allowing you to assign numeric or hashed keys on objects (or tables in Lua), but they don't call them Arrays, because they aren't.

PHP's arrays combine both vectors and associative arrays, but both numerically indexed arrays and associative arrays are types of arrays, are they not?

Arrays have expected behavior and implementations. So do hash maps. It's fine to amalgamate them, just give it the right name.

Whether associative arrays use hash maps underneath is an implementation detail, not fundamental to the interface PHP provides to [associative] arrays.

[j_col]

> ...it encourages bad coding...

I would love to explain to my boss when I introduced some bad code into our repo: "But the PHP made me do it!". Really, if you can't use a tool without blaming it for when you use it badly, well...

[CWIZO]

PHP 5.4 does NOT introduce closures, they've been in there from 5.3.

As for traits, sure but as with all things it depends on who will use them. Some will make a mess out of them, while other will use them properly. Just as with any other feature in any other language. Please stop using this tiered "reason" for why PHP is bad. It's just doesn't hold water.

[sipefree]

Sorry, I didn't mean to imply that 5.4 introduced closures, I was more speaking on a long-term level on that note.

[zombielifestyle]

* traits is a concept explored in smalltalk. surely the greates monkey patchers among us.

* array? yeah, it's called like that. it could even be named "fridge" or "smartass".

* due to the new release process php BC is guaranteed for non major versions. adaption will be fast.

* thriving ecosystems don't matter, PHP is just one possible piece in the toolchain.

[ericingram]

thriving ecosystems don't matter? that seems like a silly thing to say.

[wvenable]

Multiple inheritance is a silly implementation of traits/mixins and interfaces. MI combines implementation and type inheritance but with traits/interfaces those concepts are separate and therefore it is much more flexible.

The 'use' keyword already exists in PHP for use with namespaces; it's pretty common for C-based languages to overload common keywords.

As far as I'm aware, there are no backwards incompatible changes in this release and servers have been tracking the most recent PHP versions much better these days.

Also, array[1] is the correct terminology.

[1] http://en.wikipedia.org/wiki/Associative_array