Anthony Ferrara has a new post today getting into the details of how "equals" works in PHP at the opcode level. He focuses on the answer to a question he received:

I was asked an interesting question via email yesterday. The question is fairly simple. The answer, not so much... So, rather than reply in an email, I figured that I'd write a post about it instead. The question, simply stated, is: "When comparing a float to an integer using ==, where does the conversion happen?"

He starts with a super simple piece of test code that compares an integer (1) to a float (1.0) and walks through the process PHP takes to perform the comparison (with a double equals "=="). He talks about opcode handlers, the "fast equal function" and how it handles the casting from one type to another, C source highlights included.

Ilia Alshanetsky takes a look at type hinting in PHP (he's made some previous comments on the matter) and some of the community's comments about its suggested inclusion in the language.

There has been a lot of comments both on this blog and the internals list. There seems to be a fairly large group of core developers who like the idea as well as surpassingly large support base on the user level too (wow, didn't think that this many people want type hinting).

Despite some of the nay-sayers who don't think it's a good idea, the majority seems to approve and work has already been done on a new patch you can apply to your systems. He includes the Changelog information as well as links to the patch (txt) and a test suite (bz2).

Tibo Beijen takes his own look at some of what PHP6 will have to offer and talks a bit about how it would have helped him in a current project:

I'm currently working on [a project] where I've been experimenting with 'domain objects' having 'scalar' or 'value' objects as properties (more on that later).

The talks specifically about two of the upcoming features - type hinting and the __cast magic method that allows you to correctly cast a variable into a different type. He illustrates with some code that handles and manipulates user data and handles exceptions on an incorrect type cast.

Continuing in their security theme for the month of March, the Zend Developer Zone has posted two more Security Tips for PHP developers out there:

• The first tip (#6 on their list) talks about the benefits of casting all of the values going in to your SQL queries. This helps keep you and your data away from things like nasty SQL injection issues that could result in exposure of valuable data.
• The second tip (#7) focuses on regeneration of session IDs to help prevent fixation. They give an example of how, without it, you could inadvertently allow in unauthorized users. Thankfully, one quick function call can remedy the situation - session_regenerate_id.

Check out their full list for more great tips.

Continuing in their security theme for the month of March, the Zend Developer Zone has posted two more Security Tips for PHP developers out there:

• The first tip (#6 on their list) talks about the benefits of casting all of the values going in to your SQL queries. This helps keep you and your data away from things like nasty SQL injection issues that could result in exposure of valuable data.
• The second tip (#7) focuses on regeneration of session IDs to help prevent fixation. They give an example of how, without it, you could inadvertently allow in unauthorized users. Thankfully, one quick function call can remedy the situation - session_regenerate_id.

Check out their full list for more great tips.

While testing the eZ components framework on the latest version of PHP (PHP 5.2), Derick Rethans noticed a problem - a new "Notice" message appearing related to a __get call.

The first issue is an extra notice in some cases. This all works 'fine' with PHP 5.1, however with PHP 5.2 the [following] notice was generated for this code.

The cause? Well, the magic function __get only returns the variables in read mode so they cannot be written to. In Derick's situation, there was a foreach that was trying to use the values in a read/write mode. As a result, the error was tossed. He does provide a workaround, though, involving casting the information into an array.

While testing the eZ components framework on the latest version of PHP (PHP 5.2), Derick Rethans noticed a problem - a new "Notice" message appearing related to a __get call.

The first issue is an extra notice in some cases. This all works 'fine' with PHP 5.1, however with PHP 5.2 the [following] notice was generated for this code.

The cause? Well, the magic function __get only returns the variables in read mode so they cannot be written to. In Derick's situation, there was a foreach that was trying to use the values in a read/write mode. As a result, the error was tossed. He does provide a workaround, though, involving casting the information into an array.

PHP has a lot going on "under the hood" for each request that's made, so its no wonder that issues with PHP5 code might see some problems when shifted down to PHP4. Greg Beaver caught something in the PEAR installer centered around objects.

Recently, some code in the PEAR installer was discovered to be invalid in PHP 4. After a bit of investigation, I realized that the significant difference in the way objects are represented internally in PHP 5 was the culprit.

In PHP 5, this displays as bool(true), but in PHP 4, it displays bool(false). The reason is that in PHP 4, objects are simply glorified associative arrays, and so PHP treats the above [example] code exactly the same.

He strongly suggests that, to help with this issue, you always check to ensure (with is_object) that what you're passing is a true object.

He's made an update to the post since it was originally released, mentioning how some classes will also define their own cast handlers.

PHP has a lot going on "under the hood" for each request that's made, so its no wonder that issues with PHP5 code might see some problems when shifted down to PHP4. Greg Beaver caught something in the PEAR installer centered around objects.

Recently, some code in the PEAR installer was discovered to be invalid in PHP 4. After a bit of investigation, I realized that the significant difference in the way objects are represented internally in PHP 5 was the culprit.

In PHP 5, this displays as bool(true), but in PHP 4, it displays bool(false). The reason is that in PHP 4, objects are simply glorified associative arrays, and so PHP treats the above [example] code exactly the same.

He strongly suggests that, to help with this issue, you always check to ensure (with is_object) that what you're passing is a true object.

He's made an update to the post since it was originally released, mentioning how some classes will also define their own cast handlers.