News Feed
Sections




News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

thePHP.cc:
PHP breaks backwards compatibility
January 28, 2015 @ 10:41:22

In this new post on thePHP.cc blog Stefan Priebsch talks about some of the backwards compatibility breaks that will be coming with PHP's next major version, PHP7.

According to the PHP project's current time line, PHP 7 is scheduled to be released later this year. The version number 6 will be skipped for good reasons. As is expected of a new major release, there will be some breaks in backwards compatibility. Such breaks are always a double-edged sword: some have been eagerly awaiting the removal of legacy features, others expect that existing software keeps working without modifications. The PHP project is notorious for keeping some sins of the past dating back to PHP 3 in an effort to ensure backwards compatibility. Now, with the release of PHP 7, the decision has been made to remove some features that have been marked as "deprecated" in PHP 5.

He talks about how PHP will be "re-engineered" for this major release including a uniform variable syntax and some of the things this could break (like Magento 1). He also mentions the removal of the mysql (not mysqli) extension and a major issue - that PEAR has stopped working in recent versions of PHP7 (built from the current codebase) because of how it calls non-static methods statically.

0 comments voice your opinion now!
php7 break backwards compatibility deprecated

Link: http://thephp.cc/news/2015/01/php-breaks-backwards-compatibility

Tony Marston:
Please do not break our language
January 15, 2015 @ 09:40:25

Tony Marston has posted a plea to the core developers of the PHP language when it comes to some of the changes happening with constructors in classes: "please do not break our language."

This post is addressed to PHP's core developers who are proposing to break our beloved language yet again in the next major version of PHP (version 7) by removing functionality which has worked perfectly for years simply because it does not fit in with their ideas of how it should be done today. I am talking about PHP RFC: Remove PHP 4 Constructors (and this post on php.internals) which proposes that all code with PHP 4 style constructors be made invalid in favour of the "correct" method which was introduced in PHP 5. This is despite the fact that both types of constructor have lived quite happily side by side for over a decade and that large volumes of code, including PEAR libraries, were written in the PHP 4 style.

He suggests that this kind of change would require quite a bit of code to be changed, causing headaches for a large audience out there using older PHP code. He then gets into some of his opinions and thoughts about who "owns" PHP - is it the core development team working on the language itself, the community that uses the language (or a combination of both)? He proposes two definitions of "improvement" in respect to the needs of developers using the language and core developers. He suggests that the core developers are changing the language "just because they can" and that breaking backwards compatibility with something like this is a big mistake.

He then shares some of the comments from the php.internals mailing list on the subject of the constructor change, both for and against. He also points out a few other places where backwards compatibility was broken and the resulting changes that had to be made by developers. He suggests a "if it ain't broke, don't fix it" kind of approach

If there is a choice between a lazy or incompetent core developer doing only half a job and leaving the 240 million members of the greater PHP community to clear up his mess, then it should be obvious to anyone who has more than two brain cells to rub together that it is the core developer who needs to put in the extra effort so that the greater PHP community does not have to.
0 comments voice your opinion now!
language opinion backwards compatibility break constructor php4 php5

Link: http://www.tonymarston.net/php-mysql/please-do-not-break-our-language.html

Fabian Schmengler:
Why I Am Actively Going to Drop PHP 5.3 Compatibility
December 11, 2014 @ 12:15:30

In a recent post to his site Fabian Schmengler has proposed a PHP 5.3 "Death March" in an effort to try to drop PHP 5.3 compatibility for applications and encourage the growth of PHP 5.4 and beyond.

An alarming large amount of websites still runs on PHP 5.3, which does not get updated anymore since 2014/08/14, after one year of "security only" support. In other words, the next critical security hole will only be fixed for versions above 5.4. By the way, active development of the PHP 5.4 branch was discontinued on 2014/09/14. it's already in the "security only" phase. On 2014/08/28, PHP 5.6 has been released, on 2013/06/20, almost 1.5 years ago, PHP 5.5. So, by now, in the year 2014 everybody should work on PHP 5.5, right? [...] Almost half of the Alexa Top 1M Sites that run on PHP, state the version 5.3, ca. one quarter even 5.2, which is not supported since Jan. 2011. PHP 5.2.17 even is the most used patch version in this statistic.

He goes through some of the thinks might be contributing to this drag in adoption including the slow migration of official Linux distribution packages and the incompatibility of applications and frameworks with newer PHP versions. He makes a few suggestions of what different groups can do to help the cause - developers, project managers and hosting companies. He provides a list of things that are either deprecated in 5.4 or have been completely removed.

0 comments voice your opinion now!
php53 php54 support compatibility drop

Link: http://www.schmengler-se.de/en/2014/11/why-i-am-actively-going-to-drop-php-5-3-compatibility/

Mattias Noback:
Backwards compatible bundle releases
September 29, 2014 @ 12:31:09

In his latest post Matthias Noback talks about a problem common to Symfony bundles (and, well, software in general) - dealing with backwards compatibility and breaks that could be introduced with new changes.

With a new bundle release you may want to rename services or parameters, make a service private, change some constructor arguments, change the structure of the bundle configuration, etc. Some of these changes may acually be backwards incompatible changes for the users of that bundle. Luckily, the Symfony DependenyInjection component and Config component both provide you with some options to prevent such backwards compatibility (BC) breaks.

He breaks the post up into a few different kinds of backwards compatibility breaks that could happen and code examples of each:

  • Renaming things
  • Changing visibility
  • Changing values

Each topic also includes methods for preventing issues with older users who maybe aren't using the new features. This includes things like sane default values for new settings, renaming services and creating new extensions for working with new properties.

0 comments voice your opinion now!
symfony bundle backwards compatibility changes prevent rename visibility values

Link: http://php-and-symfony.matthiasnoback.nl/2014/09/backwards-compatible-bundle-releases/

Derick Rethans:
On Backwards Compatibility and not Being Evil
August 22, 2014 @ 09:20:55

Derick Rethans has shared some of his thoughts on how to not be evil when it comes to making changes in languages like PHP. He suggests that any backwards compatibility break should be treated with the weight it deserves and not just thrust upon users.

This is a repost of an email I sent to PHP internals as a reply to: "And since you're targetting[sic] the next major release, BC isn't an issue." This sort of blanket statements that "Backwards Compatibility is not an issue" with a new major version is extremely unwarranted. Extreme care should be taken when deciding to break Backwards Compatibility. It should not be "oh we have a major new version so we can break all the things"

He talks about the two kinds of backwards compatibility breaks: obvious things where features are removed or changed in a major way and subtle changes in how the underlying code for PHP works ("subtle changes"). He points out that most of the frustrations from users comes from the second type, making for a slower adoption rate and maybe not even adopting at all.

Can I please urge people to not take Backwards Compatibility issues so lightly. Please think really careful when you suggest to break Backwards Compatibility, it should only be considered if there is a real and important reason to do so.
0 comments voice your opinion now!
evil backwards compatibility break major version opinion

Link: http://derickrethans.nl/bc-dont-be-evil.html

Reddit.com:
Just a warning, 5.5.13 introduces a backwards incomaptability
June 02, 2014 @ 11:56:16

In this recent post to Reddit.com, they point out a recent change in the core of PHP that could cause problems with backward compatibility: a change in the serialization handling to check for implementation of the Serializable interface.

Strings requiring unserialization of objects are now explicitly checked whether the object they contain implements the Serializable interface. This solves the situation where manipulated strings could be passed for objects using Serializable to disallow serialization. An object implementing Serializable will always start with "C:" in the serialized string, all other objects are represented with starting "O:". Objects implementing Serializable to disable serialization using zend_class_unserialize_deny and zend_class_serialize_deny, when instantiated from the serializer with a manipulated "O:" string at the start, will most likely be defectively initialized. This is now fixed at the appropriate place by checking for the presence of the serialize callback in the class entry.

The change corrects a bug that has been used, in certain cases, as a work-around to create objects without calling the constructor. The correct fix for it, if you're using it in your own applications, is to call ReflectionObject::newInstanceWithoutConstructor.

0 comments voice your opinion now!
backwards compatibility break serialize

Link: http://www.reddit.com/r/PHP/comments/26w42x/just_a_warning_5513_introduces_a_backwards/

HipHop VM Blog:
Compatibility Update
April 22, 2014 @ 09:16:38

The HipHop VM blog has a new post today with some updates around the compatibility work they're doing getting popular PHP projects to work 100% on the platform (and have all unit tests pass).

Earlier this year we set an ambitious goal of passing the PHPUnit test suites of 20 popular frameworks by the end of June; at the time, we were passing on only 6! With a huge amount of help from the community (especially our OpenAcademy students), we're proud to have hit this goal more than 2 months early, and we have more frameworks expected to reach 100% shortly.

Included in their list of projects/frameworks are things like Assetic, Composer, Doctrine2, Guzzle (v3), Laravel, Mockery and Monolog. Now that they've made significant strides to get the HHVM up to a greater level of compatibility, they're going to focus in on the issues list from GitHub to resolve problems there.

0 comments voice your opinion now!
compatibility update framework project unittest bugs issues

Link: http://hhvm.com/blog/4841/compatibility-update

Anthony Ferrara:
An Opinion On The Future Of PHP
March 10, 2014 @ 09:41:40

In his latest post Anthony Ferrara shares some of his personal opinions about the future of PHP and how some of the pieces in play now might fit in.

There's been a lot of buzz in the community lately around PHP and its future. The vast majority of this buzz has been distinctly positive, which is awesome to hear. There's been a lot of talk about PHP6 and what that might look like. There's been a lot of questions around HHVM and its role in the future of the language and community. Well, let me share with you some of my thoughts in this space...

He covers a few different topics including backwards compatibility, the suggestions of a complete engine rewrite and turning the SPL all OOP. He spends most of the post talking about HHVM (the HipHop VM), how it compares to "plain old PHP" and why it's not exactly "magic".

0 comments voice your opinion now!
opinion future language hhvm hack engine backwards compatibility

Link: http://blog.ircmaxell.com/2014/03/an-opinion-on-future-of-php.html

Fabien Potencier:
About Symfony Stability over Features
April 15, 2013 @ 10:12:34

Fabien Potencier (of the Symfony framework) has a new post to his site talking about a philosophy that the Symfony framework community should work towards, providing stability over features.

Long story short: in the coming months, the Symfony core contributors should focus their efforts toward stabilizing the existing features instead of working on new ones. At this point, backward compatibility and stability are more important than everything else.

He highlights some of the points that come along with this effort including less refactoring for the sake of refactoring, fixing more bugs/edge cases and writing more tests/documentation. He gets into some of the specifics of this kind of thinking and points out the things that can and can't be changed during this time. He talks more about stability and suggests that not only can it help enhance performance but it could also help motivate more projects/corporate users to start using the framework.

0 comments voice your opinion now!
symfony stability features framework initiative tests bugs backward compatibility

Link: http://fabien.potencier.org/article/68/about-symfony-stability-over-features

Andrew Podner:
PHP 5.5 Preview New Password Hashing API
March 25, 2013 @ 12:32:26

Andrew Podner has posted about the password hashing functionality that's coming with PHP 5.5 - how it will work and some of the benefits of its use.

Recently PHP 5.5 was released into beta, which puts us one step closer to another release of PHP. This week, I thought I would spend a little time explaining a new feature that will be implemented in 5.5 that will hopefully make dealing with passwords easier for developers to grasp and properly implement. I cannot tell you the number of apps, even ones written within the last year or so, that I open up only to find either an md5 hash, or worse, clear text password storage. I keep telling myself that eventually this will come to an end, and people will stop taking the easy way out. Maybe PHP 5.5 will have made it so easy that there is simply no further excuse not to implement solid password hashing.

He includes an example of the four new functions that will come with the hashing functionality: password_get_info, password_hash, password_needs_rehash and password_verify. He includes the parameters that should be included in each call and the details from the call to get the hash's info. If you're not going to be able to move up to PHP 5.5 when it's released, you might consider looking into this compatibility library to have a similar interface and functionality (for 5.3.7 or greater).

0 comments voice your opinion now!
preview password hashing api compatibility library introduction



Community Events

Don't see your event here?
Let us know!


laravel community release install interview voicesoftheelephpant laravel5 library php7 opinion extension api language podcast series framework example xdebug introduction unittest

All content copyright, 2015 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework