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

NetTuts.com:
PHP 5.6 What's New
October 02, 2014 @ 10:58:59

On the NetTuts.com site there's a new article posted talking about some of the new stuff that comes bundled in PHP 5.6 (the first stable version of which was released at the end of August 2014).

It's been a long time coming, but we finally have a new version of PHP. With it comes a some nice, new features, improvements to existing features, as well as features that have been removed or marked as deprecated. Let's dive in and take a look at everything that's offered by the latest version.

There's several items on the list, broken up into various sections, each with brief explanations:

  • Backward Incompatible Changes (ex: json_decode, mcrypt)
  • New Features (including constant scalar expressions, argument unpacking, phpdbg)
  • Deprecated Features (call to static from non-static context, removal of HTTP_RAW_POST_DATA)

They also link to the list of all of the changed and new functions updated in the PHP 5.6.0 release and moving forward.

0 comments voice your opinion now!
php56 new feature deprecated backwards incompatible break

Link: http://code.tutsplus.com/articles/php-56-whats-new--cms-22101

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/

PHPMaster.com:
Learning Loops
December 15, 2011 @ 10:15:00

PHPmaster.com has a new introductory tutorial for those just starting out with PHP (or with programming really) talking about using looping structures for sets of data - for, while/do-while and foreach.

A significant advantage of computers is that they can perform repetitive tasks easily and efficiently. Instead of writing repetitive code you can write a set of statements that processes some data and then have the computer execute them repeatedly by using a construct known as a loop. Loops come in several different flavors in PHP: for, while, do-while, and foreach. I'll introduce you to each of them and show you how they can making repetitive tasks straightforward and easy to maintain.

The tutorial explains a use case for each of the loop types and includes a bit of sample code showing how to put it into practice. It also shares two special keywords that can be used to bypass or break out of your current loop - break and continue.

0 comments voice your opinion now!
introduction tutorial loop dataset for while foreach break continue


Rafael Dohms' Blog:
Problem Solving technique #1 Taking a mental break
February 07, 2011 @ 12:08:44

Rafael Dohms has posted a new tip for developers (and really anyone else that has to concentrate on mentally challenging tasks all day) that could sometime help you break through that wall you've hit in your code - take a mental break.

Developers are modern day artists whose masterpieces are not hung on walls but stretched out thin on web servers all over the world, yes that is very poetic, but I really try to look at developers as artists and puzzle solvers. [...] A different activity, to most its the simple act of going to get coffee or water, taking a stroll outside in the fresh air, some like sports, some like games.. everyone has their escape valve.

He gives an example of a friend (Chester) who, when he hit a mark he just couldn't pass, turned to a set of lego blocks to help clear his mind. The subconscious mind kicks in as you preoccupy the conscious and a lot of times the answer floats up to he top with little or no effort.

0 comments voice your opinion now!
problem solving technique mental break developer


Jani Hartikainen's Blog:
Three PHP mistakes that will cause you debugging nightmares
January 22, 2009 @ 12:51:50

Jani Hartikainen has posted about three simple, but hard to find, mistakes that can cause you endless frustration if you're not looking in the right places.

Here's his list:

  • Semicolon after a while - a small problem with big (infinitely looping) consequences)
  • empty() and magic __get method - __get will hit first, then empty
  • Missing semicolon after break or continue - a classic that can make switches and evaluations difficult to debug

Comments on the post include a few others: working with variables by reference, comparisons with == versus === and strpos finding the first character in a string.

0 comments voice your opinion now!
mistake semicolon empty magic break continue debug nightmare


Typical Programmer Blog:
Doing it wrong getters and setters
June 16, 2008 @ 11:19:17

According to this new post on the Typical Programmer blog, using getters and setters in your scripts only adds in a bit of unnecessary coupling and complexity to your scripts that you just don't need.

Today most of the popular programming languages support objects, limiting scope, modularity, passing by value, and sophisticated built-in types. There should be no reason to deliberately expose an object's data to the rest of the code because the language can enforce encapsulation and data hiding.

While not specific to PHP, the post does recommend against them because of one simple reason common to all languages that make them possible - they "break the encapsulation OOP offers". For them, they're like a cheat to get around bad coding practices and are not needed to make a successful application work.

0 comments voice your opinion now!
getter setter break object oriented encapsulation scope bad


PHPClasses.org:
8 defensive programming best practices to prevent breaking your sites
April 26, 2007 @ 11:11:00

As anyone who's been developing applications (web or otherwise) knows, there are certain things that you just don't do when you're doing things like adding features or changing the code of a production application. There are some general rules to follow and this new article on the PHPClasses.org website reminds us of just a few.

This article describes software development practices that have been used to prevent problems that can break Web sites.

Included in his list are things like:

  • Handle unexpected conditions Test your code
  • Monitor your site errors and act upon them
  • Do not disclose errors to the users
  • Do what you can as you can never get defensive enough
He also recommends two resources for some additional reading - the Wikipedia entry for "defensive programming" and a chapter from Getting Real (from 37 Signals) about how to "Get Defensive".

0 comments voice your opinion now!
defensive bestpractices break site defensive bestpractices break site



Community Events

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


unittest wordpress opinion development laravel5 podcast framework introduction series extension conference laravel interview library language middleware release community api voicesoftheelephpant

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