If you've heard about the release of PHP 7 but aren't quite sure what it has to offer, check out this quick post on the StartTutorial site giving you a "top five" list of things this new version of the language has to offer.

But you must be wondering why PHP named its latest release PHP 7 and not PHP 6. Reason behind it is that, many of the PHP 6 releases were already implemented in PHP 5.3 and later, there was not really a proper reason just to change the name. What I am trying to say here is that we haven’t missed anything. Just to avoid the confusion with a dead project, PHP's latest release was named to PHP 7.

Is This Hype Valid for PHP 7? What It Actually Brings Forth for the Developers? Hop on and let’s take a deeper dive. Let's check out what new features PHP 7 has to offer. And what improvements those features will bring forth.

Their top five list covers some of the major improvements in the language:

• Speed Improvement
• Implementation of Type Declarations
• Implementation of Error Handling
• New Operators
• CSPRNG Functions

There's a bit of explanation of each item on the list but you'll definitely want to refer to the PHP manual for more details and specifics on what changed in PHP 7.

In a new post to his site Volker Dusch shares his thoughts about warnings in coding style checks (and how they differ from real errors).

When it comes to coding standards there is one rule that always makes me cringe when I stumble upon it: "Lines SHOULD be less than 120 chars long. If not a warning will be issued." Let me try to make a point why I consider WARNINGS in coding guideline checks hurtful.

He defines a warning first, so there's no confusion (something that should be done, but doesn't have to) and why he thinks there's not much of a place for them in the code guidelines. He suggests that, by having them, they take away time from the real issues, the errors. He notes that "should" rules on formatting shouldn't be added to your QA tools right away. Adding too many of these that spit out too many warnings (not errors) could just muddy the waters and make the developers more confused.

The Zend Developer Zone has posted a new episode in their ZendCon Sessions series today - a recording of Eddo Rotman's talk on exception handling.

Welcome to the ZendCon 2008 edition of the ZendCon Sessions. [...] n this series we will be releasing regular sessions from ZendCon 2008 as we lead up to this year's ZendCon. This episode of The ZendCon Sessions was recorded live at ZendCon 2008 in Santa Clara, CA and features Eddo Rotman giving his talk: "Elegant Ways of Handling PHP Errors and Exceptions"

You can listen to this episode either through the in-page player, by downloading the mp3 or, of course, subscribing to the podcast feed.

Harry Fuecks wonders in this new post on the SitePoint PHP Blog "how strict is your dynamic language?"

Considering the "big four" dynamic, procedural languages; Perl, Python, PHP and Ruby, to an extent they're much of a muchness, offering only small variations on the same theme (ignoring PHP's lack of support for functional-style programming). But sometimes little things make a big difference, and perhaps most of all when your code is given input to handle which it wasn't designed for. Knocked up a simple example to compare them in this area...

He compares four languages - Perl, PHP, Ruby, and Python - by giving, for each, code examples and what the output would be, including what would error out. These examples help to illustrate his final points:

• where is the point when a fatal error should be raised?
• what is it the languages should actually complain about?

Harry Fuecks wonders in this new post on the SitePoint PHP Blog "how strict is your dynamic language?"

Considering the "big four" dynamic, procedural languages; Perl, Python, PHP and Ruby, to an extent they're much of a muchness, offering only small variations on the same theme (ignoring PHP's lack of support for functional-style programming). But sometimes little things make a big difference, and perhaps most of all when your code is given input to handle which it wasn't designed for. Knocked up a simple example to compare them in this area...

He compares four languages - Perl, PHP, Ruby, and Python - by giving, for each, code examples and what the output would be, including what would error out. These examples help to illustrate his final points:

• where is the point when a fatal error should be raised?
• what is it the languages should actually complain about?

On his Oracle blog today, Christopher Jones has posted a simple howto on getting the feedback the PHP Oracle functions throw when they error, only faster.

He includes some settings to add to the sqlnet.ora file to help speed thing along - setting the directory path to enable a different authentication syntax and changing a setting to restrict the types of connect methods the client can try.

To show how it all works together, he gives an example of the tnsnames.ora, sqlnet.ora, environment variables, and the commands he ran to test it all out.

On his Oracle blog today, Christopher Jones has posted a simple howto on getting the feedback the PHP Oracle functions throw when they error, only faster.

He includes some settings to add to the sqlnet.ora file to help speed thing along - setting the directory path to enable a different authentication syntax and changing a setting to restrict the types of connect methods the client can try.

To show how it all works together, he gives an example of the tnsnames.ora, sqlnet.ora, environment variables, and the commands he ran to test it all out.

Greg Beaver has a quick reminder on his blog for anyone out there running their own PEAR channels - "please watch pear-qa".

Just a quick note to all of you PEAR channel administrators: Please take a moment to either join the pear-qa@lists.php.net mailing list, or follow php.pear.qa at news.php.net. Why?

Every time a new release of the core PEAR package is slated, I (or whoever is in charge of the release) will post a message to the pear-qa list asking for testing of the new version 1 full week ahead of the scheduled release date. This is the one opportunity to test for critical errors that unit tests or myself have missed.

There's a specific instance he mentions of where this happened (in 1.4.7 involving channel names with a "-") and the code was still released. Of course, once it was applied, many users were upset that their installs had just "stopped working".

It would be very helpful to have channel administrators take a second to try out stable versions of PEAR as they approach release.

Greg Beaver has a quick reminder on his blog for anyone out there running their own PEAR channels - "please watch pear-qa".

Just a quick note to all of you PEAR channel administrators: Please take a moment to either join the pear-qa@lists.php.net mailing list, or follow php.pear.qa at news.php.net. Why?

Every time a new release of the core PEAR package is slated, I (or whoever is in charge of the release) will post a message to the pear-qa list asking for testing of the new version 1 full week ahead of the scheduled release date. This is the one opportunity to test for critical errors that unit tests or myself have missed.

There's a specific instance he mentions of where this happened (in 1.4.7 involving channel names with a "-") and the code was still released. Of course, once it was applied, many users were upset that their installs had just "stopped working".

It would be very helpful to have channel administrators take a second to try out stable versions of PEAR as they approach release.

In this blog post today, ephemera looks at a few of the common PHP errors those new to the language might encounter and an inerpretation of each.

I'd like to dispell the myth that errors are a bad thing. Errors are not a bad thing. Errors are a good thing! They tell you exactly what to fix, and exactly where to fix it. The only mystery is in actually interpretting the language of the error, which is another skill that beginning coders have yet to master. What does the PHP interpreter really mean when it says "unexpected T_VARIABLE"? What's a T_VARIABLE, anyway?

This document is the first in a series that will attempt to help you decode error messages. This version is aimed at very new programmers, working in PHP.

The remainder of the post looks at four of the common errors that might pop up - "unexpected T_VARIABLE", "Maximum execution time exceeded", "Undefined index", and "Syntax error". Under each, she talks about what they mean and how to catch what they're referring to. There's also an example for each to show what the error-causing code might look like.