PHP 5.6 – looking forward

Having taken a look in the past, now it’s time to look into the future, namely 5.6 (PHP 7 is the future future, we’ll get there eventually). So I’d like to make some predictions of what would work well and not so well and then see if it would make sense in two years or turn out completely wrong.

High impact

I expect those things to be really helpful for people going to PHP 5.6:

Constant expressions – the fact that you could not define const FOO = BAR + 1; was annoying for some for a long time. Now that this is allowed I expect people to start using it with gusto.

Variadics – while one can argue variadics are not strictly necessary, as PHP can already accept variable number of args for every function, if you’re going to 5.6 the added value would be enough so you’d probably end up using them instead of func_get_args and friends.

Operator overloading for extensions – the fact that you can sum GMP numbers with + is great, and I think more extensions like this would show up. E.g., for business apps dealing with money ability to work with fractions without precision loss is a must, and right now one has to invent elaborate wrappers to handle it. Having an extension for this would be very nice. Finding a way to transition from integer to GMP when number becomes too big would be a great thing too.
Still not convinced having it in userspace is a great idea, what C++ did to it is kind of scary.

phpdbg – not having gdb for PHP was for a long time one of the major annoyances. I expect to use it a lot.

Low impact

Function and constant importing – this was asked for a long time, but I still have hard time believing a lot of people would do it, since people who need imports usually are doing it in OO way anyway.

Hurdles

OpenSSL becoming strict with regard to peer verification by default may be a problem, especially for intranet apps running on self-signed certs. While this problem is easily fixable and the argument can be made that it should have been like this from the start – too many migrations go on very different paths depending on if it requires changing code/configs or not.

Adoption – again, with 5.5 adoption being still in single digits, I foresee a very slow adoption for 5.6. I don’t know a cure for “good enough” problem and I can understand people that do not want to move from something that already works, but look at the features! Look at the performance! I really hope people would move forward on this quicker.

While 5.4 will always have a special place in my heart, I hope people now staying on 5.2 and 5.3 would jump directly to 5.6 or at least 5.5. The BC delta in 5.5 and 5.6 is much smaller – I think 5.3->5.4 was the highest hurdle recently, and 5.4 to 5.5 or 5.6 should go much smoother.

Anything you like in PHP 5.6 and I forgot to mention? Anything that you foresee may be a problem for migration? Please add in comments. 

5 thoughts on “PHP 5.6 – looking forward

  1. Pingback: Constant Consistency | Sharon Lee Levy's Blog

  2. “…people who need imports usually are doing it in OO way anyway…”
    Well, yeah, that’s because we couldn’t do it any other way before. I know I’m not alone in having a bunch of utility functions wrapped up in classes when they really don’t need to be; they’re called statically and have little or no relationship to each other; they’re just stand-alone helper functions.If I could have imported them as functions in the past, then I certainly would have done.

    Re adoption rates: I’ve had enough arguments with sys admins reluctant to upgrade to know that my position of wanting the latest and greatest is not always compatible with the sys admin need to maintain stability, security and up-time. I’m lucky in that I do have direct communication with my sys admins and I can request specific software versions; most PHP devs out there don’t have that luxury; they get given a box with PHP on it, and have to live with whatever version it happens to be. Preaching to PHP devs to upgrade isn’t going to help them; you need to preach to the sys admins and the Linux distro providers.

  3. I like the new pow operator ** and feel that its entry into PHP will make it more pleasant for those dealing with exponentiation. The accompanying **= will hopefully prove useful, too. Also, nice to see that finally PHP can handle large file uploads in excess of 2GB

    • ** looks like really small thing – how much exponentiation one does in PHP? I can’t remember doing one in the last year.
      Big file uploads is good, but that’s rather a bug fix that a new feature in my book🙂

  4. Pingback: PHP 5.6 – looking forward | PHP Information

Comments are closed.