Eran Gelperin gives an overview of the current state of overloading abilities PHP has in a new blog post today:

Operator overloading is a programming language features that allows operators to act differently depending on the type of data they are operating on. Since OOP lets us create custom types (classes), there are plenty of opportunities to do useful and interesting code manipulations using operator overloading.

He talks about magic functions, the additions that the SPL made, the PECL addition operator and how much its currently being discussed on the PHP internals list.

Lucas wrote in to tell us about a new job offering over at Facebook, the popular social networking site, for a PHP developer in the Palo Alto, CA area:

Facebook is seeking a PHP Internals Engineer to join the Product Engineering team. The position is a full-time position based in our main office in downtown Palo Alto. The PHP Internals Engineer will report to the VP of Engineering.

The position requires a good knowledge of C, extensive experience with PHP (obviously), good interpersonal skills, and a BS/MS degree in computer science or engineering is preferred. You can find the rest of the requirements in the entry on their site.

To send along your information, email it to resumes@facebook.com along with the name of the position.

Sara Golemon, inspired by an IRC discussion has gathered together some of her thoughts on "using PHP's string interpolation without using an optimizer".

She explains how a simple string (an echo statement) is interpreted into a simple compilation structure. Her next step, though (placing a variable inside a string) yields something that seems more complex than it should be. A concatination example simplifies things down a bit, but, oddly enough, it gets even better when a comma is used instead of a period to concatinate. She also gives an example of a heredoc statement that doesn't conform to the interpolation standards you'd think.

Why does this happen? Because there are about a dozen ways that a variable can be hidden inside an interpolated string. Similarly, when looking for a heredoc end-token, the token can be an arbitrary length, containing any of the label characters, and may or may not sit on a line by itself. Put simply, it's too difficult to encompass in one regular expression.

She specifically mentions the APC caching system and its built-in optimizer to help with some of these issues. It pulls the interpolations back down to a size they should be and anticipating operations by pre-resolving things like constants and scalar expressions.

Of course, not everyone can install this pacakge, so she suggests an alternative:

You can still avoid 90% of the INIT_STRING/ADD_STRING dilema by simply using single quotes and concatenation (or commas when dealing with echo statements). It's a simple trick and one which shouldn't harm maintainability too much, but on a large, complicated script, you just might see an extra request or two per second.

On PHPKitchen today, Demian Turner has posted this interesting item about an improved "PHP shell" that has been developed by Jan Kneschke.

For the last few years I've been trying to build the considerable patience required to use the default shell available in PHP. If you have any parse errors, it dies, and of course you have to keep typing "

Jan's version is a considerable improvement, and although it doesn't yet handle up-arrow for previous LOC or back-arrow in case you type your parentheses first and want to fill in the variables after, it's a welcome relief to work with. I'm sure it will delay the capitulation when you give up and create a stupid file and request it in a browser just to test some little PHP detail.

You can check out the details here or just download the files directly from here

From Heigl's blog today, there's his look at some of the issues that surrounded the release of PHP 5.1.0 (and the quick following of PHP 5.1.1).

As many have noticed 5.1.0 had some issue when it was released, like for starters it introduced a empty date class by default which effectively killed scripts that used PEAR::Date.

As one can see in this excellent rant by Ilia there are different views on how this should have been handled (also read the internals ML if you need even more reading material), namely why PEAR was polluting generic names and why they didn't fix it right away so PHP could get the glorious name of Date.

Heigl takes the side of the internals developers, that internal PHP should win out over PEAR on this issue. There's been a pretty large debate raging on about this one - and, even with the (pullback) release of PHP 5.1.1, it goes on as an issue to address in, say, PHP 5.2? (Or maybe they'll just wait until 6 and lump it all in...)

In this new post from Andrei Zmievski's blog today, he has a bit of a reminder for anyone out there participating in the php-internals mailing list - "don't forget to participate".

The latest round of discussions on the php-internals mailing list highlights something that has been a pet peeve of mine for a long time. As PHP became more and more popular, the number of people subscribed to the mailing list has grown as well, and lately this has resulted in a slew of interminable threads of will-crushing length.

A whole lot of these folks are under the impression that one can simply subscribe to the list, read discussions while lurking or semi-lurking, and start to vote on things that affect intimate parts of the language. That is... kind of gall-ish, if you ask me.

His recommendation so that you will be taken seriously (and have your opinion count) on the list? Participate - good, valid, throughtful participation - that contributes a full and complete thought to the conversation on the list. And no, "+2 for namespaces" doesn't count...

John Lim looks at the release of PHP 5.1 with a bit more skeptical eye in his latest blog post today.

Well PHP 5.1.0 is out. This is a monumental piece of work, and congratulations to the PHP 5 internals team for all the hard work. However it feels rushed through the door. Apparently there are compatibility problems (with typecasting when parameter passing, the prototype date class, and possibly other stuff.) Wait for the patches.

He also mentions some of the turmoil that's been going on on the PHP internals mailing list lately, especially pre-5.1 release...