PHP 5.5

https://github.com/php/php-src/blob/php-5.5.0/NEWS

by dave1010uk • 13 years ago

106 109 13 years ago

github.com

dave1010uk3• 13 years ago

Download: http://php.net/get/php-5.5.0.tar.bz2/from/a/mirror

thejosh2• 13 years ago

Biggest change? - Drop Windows XP and 2003 support

masklinn• 13 years ago

And PHP finally gets finally, I guess.

dave1010uk3• 13 years ago

Most interesting things for me:

* PHP is getting the yield keyword (i.e. generators and coroutines), which many other languages have had for a while.

* A sensible and simple built-in password hashing API

* Error when using the deprecated mysql extension, which should hopefully get more people moving to PDO (e.g. WordPress: http://core.trac.wordpress.org/ticket/21663 )

doppel• 13 years ago

For the last one, won't people just move to the mysqli_* function group instead? It's almost identical API-wise.

shirederby• 13 years ago

Line 11 is "Added simplified password hashing API"

rmccue• 13 years ago

I'm trying to push for that WordPress ticket, but it's unlikely that we'll get any significant traction for a while. The database class in WP (apart from being fairly horrible) is a huge component to make major changes to like that, and we have to consider backwards compatibility.

Here's hoping it gets merged in the next 5 major releases. I'm not holding my breath.

coldtea9• 13 years ago

Only if you're using them in the first place. Most people deploy in Linux. Hence, totally irrelevant for them.

thejosh2• 13 years ago

Deploy yes, but not develop with. Most people don't really use virtual machines (vagrant and friends) if they have XP.

magnetikonline• 13 years ago

A nice meaty change list there. Get compiling :D

manuletroll3• 13 years ago

Am I the only one thinking PHP needs more stuff removed rather than added ?

Rygu• 13 years ago

If you mean deprecation and then removal, yes. Search for deprecation in the changelog to see that it's happening already! ;)

skrebbel• 13 years ago

Yes.

Removing stuff from a programming language has virtually no benefit and a huge real economic cost. That, of course, is under the assumption that the programming language has users.

I could see them deprecating some stuff, and adding yet another E_EVEN_STRICTER level that tosses ugly notifications when deprecated things are done. That would be nice.

mgkimsal• 13 years ago

IIRC E_DEPRECATED notices are triggered when deprecated stuff is referenced.

http://php.net/manual/en/errorfunc.constants.php

E_DEPRECATED - Run-time notices. Enable this to receive warnings about code that will not work in future versions. (Since PHP 5.3.0)

cousin_it3• 13 years ago

Hmm, but does it have to be that way? What if every new version of a programming language came with a tool that converted old source code to new source code, like Python's 2to3? That way you could cleanly handle removals, renamings and all sorts of other changes... maybe even provide implementations of old library functions in terms of new ones.

TheAnimus3• 13 years ago

I sort of agree with you, but then I come at it from the view point of why choose PHP? Myself, I can't think of a single awnser, but then again I'm the kind of person who learns a programing language or paradigm for fun.

However there is an elephant in the room with PHP, it has, quite frankly some terrible creations made by it. In much the same way MS had a whole bunch of technologies around DCOM and the like which suddenly found themselves disabled and strongly advised against use in XP SP2. I think PHP really does need to try and clean up its image.

The whole 'lets go find some sql injection vulns on github' game demonstrates many people still use the tool badly.

At what point does someone say, that they should re-design the tool, so that they encourage better use.

I'll be honest, if I hear someone say "we're using php for this" I assume its just because they are ignorant of other languages. I can't think of any problem I've been faced with, where PHP is the best solution.

So ultimately, if your going to try and remove stuff, why bother, you'll only break the existing projects, rather than improve them. The best thing is to treat the language as depreciated.

wr0ng• 13 years ago

From an engineering perspective you're probably correct. However, from a commercial perspective (be it long-term support, business continuity, cost of developers/support) PHP is one of the best solutions.

kmage2• 13 years ago

I think PHP really does need to try and clean up its image.

Sorry, but you obviously have not been taking notice over the past year or two. PHP really has been cleaning up its image. Go have a look at PHP-FIG, composer and packagist for starters.

Yes, there are problems. Yes, some/most may think that there are better solutions. But to think that PHP has not been "cleaning up its image" is just wrong.

manuletroll3• 13 years ago

Well actually I don't use PHP that much anymore, but I do keep an eye on it; there's been a lot of improvements, mostly on the ecosystem side. It's definitely not my language of choice, but one still has to eat, and PHP jobs are unfortunately way more common than most other stacks around here, outside of the enterprise stuff which I'm currently doing.

toble• 13 years ago

But isn't that the point of PHP? Removing stuff creates version instability. If you want something lower level then there's lots of alternatives.

Udo6• 13 years ago

Removing things from a language is a difficult proposition. I think increasingly a case could be made for a cleanup of many of the core functions, and I personally would remove some of the OO sugar coating added as of late. But that's probably more trouble than it's worth.

As core function naming and argument order is a pet peeve of mine, I would welcome a cleaned-up API2.0 if you will, while beginning the long phase-out of the old one.

I would agree though that some features should not have been added in the first place. But they're in now, and once they are in they should probably stay in for a while.

manuletroll3• 13 years ago

That's pretty much what I had in mind with this comment, I should have expanded it a bit. What grates on my nerves when writing PHP is indeed the awfully inconsistent standard library. Though some syntax choices (namespaces for instance) are also pretty weird.

maratd3• 13 years ago

Am I the only one thinking PHP needs more stuff removed rather than added ?

You can remove things yourself? The PHP codebase is extremely modular. Just compile your own PHP and leave anything you don't want out. Has a wonderful --disable-all flag and then you just add the stuff you need.

angersock2• 13 years ago

They added coroutines in a minor number patch. wat.

pilif2• 13 years ago

Just as rails has added the asset pipeline in a minor number patch. Or as ruby changed to unicode with 1.9. Or as python added a whole new syntax for exceptions with 2.6. As with many other languages, incrementing the minor number usually means quite big changes while more or less keeping backwards compatibility.

Changing the major number is something that's done when backwards-compatibility is hugely affected.

The exception is probably ruby which greatly broke backwards-compatibility with 1.9 (unicode) and mostly just changed internals with 2.0

angersock2• 13 years ago

Oh, I'm not about to hold up ruby or python as shining beacons here--though I will smugly admit that the rubyists seem to be pretty fast at updating their gems.

Still, it's weird practice nonetheless, right?

rjknight4• 13 years ago

PHP's versioning has generally been a bit weird since the abortive PHP 6 project. PHP 6 was meant to be the version that implemented full unicode support, but this proved to be very difficult, with the result that major new features had to go into the 5.x branch while 6.x remained in development (which, I guess, it still is).

5.3 added closures and 5.4 added traits, so adding coroutines in 5.5 is not inconsistent with past behaviour. I guess it's sort-of like how every version of OSX is 10.x, even though there have been massive changes between 10.0 and 10.8; it makes more sense to think of 10.8 as being 'OSX version 8'. Likewise 'PHP5' has been around for so long that nobody really looks at the major version number any more.

agwa• 13 years ago

It seems like every major software project reaches a point where the major number just stops changing. Linux too - it became clear that it was going to be 2.6.X.Y forever, so they renumbered to 3.X.Y to make the version string shorter.

I guess it's a sign of maturity: the project has reached a solid codebase with good development practices so there won't be any more overhauls that warrant a major number increase.

dave1010uk3• 13 years ago

This is standard in PHP's release process [0]. New features are fine, as long as they don't break backwards compatibility. This is the same as semantic versioning [1].

[0] https://wiki.php.net/rfc/releaseprocess

[1] http://semver.org/

rjknight4• 13 years ago

Except that PHP's 'minor' version changes do break backwards-compatibility:

http://www.php.net/manual/en/migration55.incompatible.php

http://www.php.net/manual/en/migration54.incompatible.php

http://www.php.net/manual/en/migration53.incompatible.php

http://www.php.net/manual/en/migration52.incompatible.php

As someone who has maintained open source software for PHP, the idea that there's backwards-compatibility between different versions of 5.x is not really correct. From a features perspective I think this is a good thing - PHP needs to move forward - but it's wrong to say that PHP entirely follows the SemVer standard.

coldtea9• 13 years ago

Not all versioning schemes are the same. You have to know what the versioning scheme means in a particular project to judge that.

The minor number in PHP does not mean bugfixes and small stuff only, as does in some project. The second even minor-er (!) number (.x.y) is for that.

PHP has always added tons of stuff in .x releases (closures are another example).

Python also adds major features in minor versions all the time. You can find similar grand changes between 2.x releases.

conradfr2• 13 years ago

I can see array_column being useful instead of using foreach on sql query results.

dexen• 13 years ago

...or PDOStatement->fetchColumn('column-name').

ihsw• 13 years ago

PDOStatement->fetchColumn() accepts only integers as an argument.

http://ca.php.net/manual/en/pdostatement.fetchcolumn.php

conradfr2• 13 years ago

It does not do the same thing, does it ?

http://benramsey.com/blog/2013/03/introducing-array-column-i...

scribu• 13 years ago

It's useful for a whole bunch of things!

I had it implemented in userland as a utility for years.

desas• 13 years ago

It's useful for lots of things, I implemented something similar as array_pluck recently and immediately noticed lots of places where it could have been used.

pjmlp2• 13 years ago

Now I just have to wait my ISP would eventually some day upgrade from 5.3.

coldtea9• 13 years ago

Or you now, get with the program and get a VPS like everybody else.

voltagex_• 13 years ago

I don't think this is a solution for everyone. Even though VPSes are cheap, if you're not making any money from running them, they're still a cost to you.

pjmlp2• 13 years ago

I just want to eventually refactor some code to take advantage of more recent features, what I pay for the site and what I do with it, is not worth the trouble to migrate to a VPS.

michh2• 13 years ago

Seems like a bunch of really welcome improvements. Wish I hadn't known about them though, as I probably won't be able to use them in our production environment for the next 2 years or so.

Tomdarkness• 13 years ago

Can I ask why it will take so long? I'm working on a medium to large scale project and we will be likely rolling the new version out to our staging environment within a week and assuming everything goes smoothly to the production environment not long after that.

griffindy• 13 years ago

If michh is working on plugins for other people, shared hosts can be pretty behind on their PHP versions. I just had to backport a wordpress plugin to 5.2(!), which came out in 2006.

EDIT: meant PHP versions, not plugins.

michh2• 13 years ago

My biggest nemesis: legacy...

porker• 13 years ago

Best resource for learning about coroutines in (PHP|general)?

stevelaz• 13 years ago

Check out Lua Coroutines, here's a starter link: http://lua-users.org/wiki/CoroutinesTutorial

dkhenry7• 13 years ago

And what I still don't see is anything saying they are taking their performance problems seriously. Still nothing saying they are fixing their documentation. Nothing addressing their hodgepodge of legacy code and mixed methods of implementing features. Its like their upset that people have moved on, but instead of providing a better core for people to build products on they keep adding chrome to the fringes of the language hoping to get more people sucked into developing for it only to realize that once they do anything of significant size in PHP they will need to do a full rewrite into a language that can actually scale or turn to a PHP to C++ lexer to actually get a product that doesn't also server as a Data center toaster oven.

RossM2• 13 years ago

Out of interest, what do you find wrong with the documentation? I've always found it pretty comprehensive and relatively easy to navigate.

Zergy• 13 years ago

I personally found it very incomplete. The comunit makes up for it but quite often there were large gaps exspecially regarding edge cases and details on how functions would behave if they failed. The comments did a really good job of filling in these gaps but the documentation alone was often inadiquate to understand how the code would behave.

Navarr• 13 years ago

Generally very little, but there are things like http://php.net/trader_stoch

dkhenry7• 13 years ago

http://www.php.net/manual/en/internals2.apiref.php

juice13• 13 years ago

5.3 and 5.4 had significant performance increases. 5.5 has integrated opcode cache. IMO, PHP has one of the best documentations of any programming language. Many bad bits have been deprecated in recent versions and there are PSR recommendations which make it easier to write decent interoperable code. PHP is growing up.

However, if you don't like it, nobody's forcing you to use it. Just walk away.

dcc1• 13 years ago

This ^

I find the people doing the moaning about PHP are the noobs who are regurgitating what they read or heard elsewhere in order to appear smart, Having moved to PHP 10 years ago after C and Java and .NET development I am happy for having changed direction and have made a bootload of money and saved alot of time thanks to PHP over the years.

verelo• 13 years ago

Great response, i love the PHP documentation. Writing clean PHP is not hard, its just easy to write bad PHP. In general it is one of the simplest languages to get started with and it'll stick with you a very long time because of its flexibility.

cwt137• 13 years ago

The PHP team does take speed seriously and just about every minor release gets a little bit faster, sometimes alot, like 20% faster. I'm not even including stuff like the opcode caches that are built in now like APC or Zend Optimizer+. Lots of times, minor releases also get more efficient with memory usage too. If you are not happy with the speed, PHP is an open source project and you can contribute patches to speed it up.

Documentation gets fixed all the time. PHP has been historically known as having one of the best docs and the docs have contributed to its success. As with the source code, the docs are open to contributions if you feel the need to modify or add something.

That's funny you say PHP can't scale. Facebook, Yahoo, Etsy and a whole lot of other big PHP shops get more traffic than most of us will ever see in a few life times. So, PHP scales. Even pre-Hiphop Facebook got more traffic than most of us will will ever see. Many times scaling is more about architecture design/implementation than language. App Engine is all about scaling and PHP runs on it. Oh by the way, at scale, every language is a data center toaster oven.

PHP people aren't mad that people are leaving. They are happy that it is still the #1 language used for web development.

The only valid argument you have is the mixed methods and stuff. It would be cool to fix, but it would mean seriously breaking the API and would cause a lot of confusion. Every minor release breaks the API a little bit and people are unhappy. So, this might never change. I don't see it as a big deal because if you are a great programmer, you know the quirks of your language and they don't throw you off. Also, there is auto-completion and docs for you to look up things if you don't know stuff off the top of your head.

It is true that lots of developers have left PHP, but it is a falsehood that everybody is moving away from PHP. If that was the case, PHP wouldn't be running on 75% of the public facing web hosts out there. There would be a business incentive (because they are using another language) to get PHP off their box. They could devote those resources to the new language they are using. The 75% number shows that their is no mass exodus, but definitely evidence not everybody is using PHP.

Oh, by the way, PHP is open source so you can help contribute to its continued success if you like. If somehow you have already contributed, don't stop till the work is done.

dkhenry7• 13 years ago

I do contribute to PHP. I have had a few patch submission fixing bugs here and there, but then you run into this

    http://www.php.net/manual/en/internals2.apiref.php

This is PHP's documentation for fixing things internally to it. Which would be fine if the internals made any sence whatsoever, but between the implementation of steams and the abmismal design of zval's there isn't much to logically make sence of.

And this isn't just well if you find it lacking its open source so make it better. We have we made better PHP's and named then things like Node.js and Python. Why would I implement a JIT in PHP when I could just use V8 and have an awesome runtime right out of the box ? Imperically PHP isn't nearly as fast or efficient as other languages, that’s not just an opinion it's been shown in multiple benchmarks and tests. I know it can be used for doing useful things and can even be used for large projects. I work on one of those daily, the issue is no one seems to care that as a platform PHP is _not_ a good choice any more, and increasingly the community isn't making a point of steering the platform to where it is a good choice. They just rattle off the same talking points of "Well facebook uses it" and "XX% of websites are using PHP so clearly it is good"

You want a good PHP release?

Provide documentaiton on the entire platform (http://www.php.net/manual/en/internals2.apiref.php)

Fix the zvals to make thbem memory efficient

Speed up the core ( not a opcode cache a real tracer and JIT )

Then add in yield and continuations, because without the other parts no one should care about language niceties, because no one should be using the language.

jtreminio2• 13 years ago

Another person who knows nothing about PHP, yet still has an opinion on it? Color me shocked.

j_col2• 13 years ago

And what I still don't see is anything saying they are taking their performance problems seriously.

Hmmm, you have heard about PHP-FPM right? And the built-in APC cache? And HipHop?

Besides, in my experience performance problems will arise with other parts of your architecture a lot sooner that your application code (e.g. database if you're not clever about load balancing and caching), regardless of what language you are using. Network calls and disc I/O are a lot more expensive than CPU cycles in your app code.

Still nothing saying they are fixing their documentation.

Define fixing. It works fine for me as-is.

Nothing addressing their hodgepodge of legacy code and mixed methods of implementing features.

Again, define addressing. Deprecating? They're doing that. What else do you suggest, breaking existing popular applications by removing legacy code that you find offensive? Let me know how that works out (see Perl 6, Python 3...).

Its like their upset that people have moved on,

Define people. Seriously.

but instead of providing a better core for people to build products on they keep adding chrome to the fringes of the language hoping to get more people sucked into developing for it only to realize that once they do anything of significant size in PHP they will need to do a full rewrite into a language that can actually scale or turn to a PHP to C++ lexer to actually get a product that doesn't also server as a Data center toaster oven.

Wow, that needs a comma.

I hate these ranty posts attacking open source projects. Have you any idea how many hours of dev time went into PHP 5.5, free of charge? If they work that hard to build something this significant for the community free of charge, the least they deserve is your respect. In the meantime, feel free to go use Scala/Ruby/Node/whatever excites you.

dkhenry7• 13 years ago

I do respect the work they have done to the language, and I have also spent many hours contributing back to PHP and the various projects in the PHP community, however that doesn't change the fact that the _community_ collectively has a hard time dealing with the hard issues that need to be solved. Proof of that is the response you see right here on this forum. Mention how PHP's internals are lacking and get told how I must be a n00b and should just turn on APC. Until PHP starts to take its core defects seriously I don't think it will ever make significant progress as a platform.

Udo6• 13 years ago

Could you be more specific? What's your performance problem? Where do you think the documentation is bad? In my experience these are two areas where PHP is doing pretty well.

I share your reservations about legacy API (the naming scheme and parameter order of many standard PHP functions should have been cleaned up years ago) and I think adding yet another slew of OO sugar coating isn't going to encourage developers to write better PHP apps, quite the contrary.

Its like their upset that people have moved on, but instead of providing a better core for people to build products on they keep adding chrome to the fringes of the language hoping to get more people sucked into developing for it only to realize that once they do anything of significant size in PHP they will need to do a full rewrite into a language that can actually scale or turn to a PHP to C++ lexer to actually get a product that doesn't also server as a Data center toaster oven.

Wow. This big run-on sentence about not being able to do "anything significant in PHP" is just not true, and that's me parsing it generously. Big projects can and do run on PHP. It's a valid choice. If you're using PHP for genome sequencing analysis, you're not using the right tool to begin with - but the same applies to pretty much any other web language as well.

dkhenry7• 13 years ago

When I say documentation I mean the internals of PHP. Here is their documentation page

http://www.php.net/manual/en/internals2.apiref.php

nahreally3• 13 years ago

What would be valid choices for using PHP today if not for dealing with legacy code bases? It's the only thing you know? You don't have money to pay programmers for other languages? (PHP devs are commonly the cheapest)

newbie12• 13 years ago

The performance differences between all of the major scripting languages -- Ruby, Python, PHP -- are insignificant, unless you are operating at Facebook scale (and Facebook, which still uses PHP, supports the HipHop project). Your web app bottleneck is not going to be PHP. Plus the PHP community is coalescing around Symfony2, which is a best-of-breed framework. Things have never been better in PHP land.

smaili• 13 years ago

PHP - where technology meets obesity :)

krapp• 13 years ago

It's not fat... it's overloaded...

bratao• 13 years ago

You can have a modern development framework for php. You guys should try http://laravel.com/ such a fresh air into php development.

kodablah• 13 years ago

One of the most overlooked features of this release is the "::class" option. Using fully qualified string literals for type (class, interface, and trait) names has really hurt refactorability.

zemo• 13 years ago

Exceptions can be thrown into the generator using the Generator::throw() method.
Rewinding a generator

...wut

PHP 5.5

Related Stories