Matthew Weier O'Phinney has a new post to his blog today looking at one of the tools the Standard PHP Library (SPL) has to offer developers - the SplPriorityQueue (PHP 5.3+)

SplPriorityQueue is a fantastic new feature of PHP 5.3. However, in trying to utilize it in a few projects recently, I've run into some behavior that's (a) non-intuitive, and (b) in some cases at least, undesired. In this post, I'll present my solutions.

He talks about the "first in, first out" nature of queues and how it differs from a stack (including links to some of the other SPL offerings for both). He then moves into the problems he was seeing - that iteration removes values from the heap and the unexpected order of equal values in the queue. To solve the first problem, he creates an "outer iterator" that creates an "innerQueue" that's protected. The solution for the second issue - the random queue order - is a simple one: priority indexes aren't required to be integers. Strings can be substituted to help make things a bit more unique.

Andrew Curioso has a post to his blog looking at error handling in PHP 5.3, specifically in creating a "stack" that can provide more than one error handler at a time.

As you may know, set_error_handler can be used to set a custom error handler in PHP. It will catch any errors that happen in the script (with a few notable exceptions). If the function returns false then error handling resumes as normal; otherwise it is assumed that the custom handler took care of things. The problem is that you can only have one error handler active at one time. The purpose of this code is to provide a error handeling stack for PHP.

His example uses closures, so pre-5.3 installs won't be able to use it, but it's an interesting proof of concept to show how you could set four different error handlers on one execution. A code snippet is included to show how it all works.

New on his blog today, Simon Jones has posted a handy guide for those using the Zend Framework out there to the stack index for plugins the framework uses.

Zend Framework Controller plugins are a powerful way to inject logic into your controller system at various points, such as before and after an action dispatch. Plugins are run in the order they are added, though it is possible to change the order by defining a custom stack index. ZF internal plugins such as Zend_Controller_Plugin_ErrorHandler, which displays a nice Error 404 page, has a stack index of 999 to ensure it runs at the end of any plugin cycle. However, it's not so obvious from the ZF manual how to set a custom stack index.

He shows how to use the second parameter of registering a plugin to define the stack level and how to get the listing of the current stack to see just where yours might need to be placed. He also includes code samples and an output example of the default Zend Framework stack.

In this new article from Developer.com they take a look at some of the different web application stacks (including LAMP) and offer some advice as to which might be the right fit for you and your application.

Critically examining the underlying architecture for a web application is an important step in defining the end product. That explains why one of the first questions that developers ask each other is: "what stack are you using?"

They evaluate:

• LAMP Stack
• WISA Stack
• Java Web Stack
• SQL Anywhere for the Data Tier

They make recommendations for three kinds of users - start-up/hobbyist, SMB developers and enterprise-level developers.

On DevShed today the latest article in their XDebug series has been posted, a look at tracking the function call stack with help from functionality the extension provides.

Despite this inconvenience [pf not being able to get more in-depth], in this final part of the series, I'm going to show you how to work with a function of the library called "xdebug_get_function_stack()." This function can be used to keep track of the stack of function calls generated by a PHP script, in this manner completing this starting guide on this helpful extension.

After reviewing the script from the previous part (using xdebug_time_index) they get into this new function and what sort of output it provides. The stack is the trace of what functions and values were passed around in the script including information like the function name, parameters and the file it was in.

On the Blue Parabola blog Matthew Turland has written up a post about a PHP something that might need a bit more love - the Standard PHP Library.

If any PHP extension is underrated, it's probably the SPL (Standard PHP Library). From what I can tell without having been involved in its development, its purpose is somewhat similar to the STL. A while back, it was useful mainly for allowing class instances to be iterable and simulate array access. [...] Using the SPL classes actually turned out to be pretty straightforward once you got your hands on a good starting guide or two to help you beat the learning curve.

He mentions a few of the things offered by the SPL like the SplFixedArray/SplFastArray, Iterators, SplDoublyLinkedList, SplStack and SplQueue (among others). He also includes some benchmarks running standard code (like normal arrays) against a SPL counterpart - the SPL side beat the normal side hands down. Check out the full post for all of the numbers and comparison types.

Continuing on his his series looking at improvements in the upcoming PHP 5.3 release, Johannes Schluter uses this new post to look at some of the new data structures their update will have to offers in the Standard PHP Library.

In the programming world there are quite a few well understood and explored data structures. Which are commonly used in tons of applications, still the only things PHP offered till 5.3 in regards to structuring data were arrays (more precise: hash tables) and objects. So people had to either abuse them for other structures or implement the structures themselves on top of these. Thanks to Etienne things now are changing and PHP's Standard PHP Library (SPL) extension will offer quite a few standard implementations of data structures.

These new data structures are SplDoublyLinkedList, SplStack, SplQueue/SplPirorityQueue, SplHeap/SplMinHeap/SplMaxHeap and SplFixedArray. He explains a bit of what they are and more detail on one specifically - SplFixedArray.

In a new blog post, Chris Hartjes asks what's the next stack coming up on the horizon. LAMP has been the king for so long now it's hard to think about what might be next, but he takes a stab at it:

So the next thing I've been wondering about is about what future PHP stacks will look like, at least on the open source side of things. Have we gotten to the point where this is as good as it gets?

He looks at other stacks he's been working with (like LNNP - Linux, nginx, Postgres and PHP) as well as the question of limitations. Are we limiting ourselves by relying on LAMP too much? What else is out there? Does Javascript have a permenant place in any of this? (jLAMP anyone?)

ITJungle.com has posted another article in their series looking at PHP on IBM's i5/OS platform that's already included an overview of System i and a very basic look at PHP's structure.

This article provides an overview of the API toolkit, and a collection of Application Programming Interfaces (APIs) that facilitate PHP programs accessing and working with i5/OS objects.

The article comes complete with diagrams of the stacks for both LAMP and iADP as well as an overview of the Zend Core API and a code example of how to make a connection to the backend and send off a message (SNDMSG) to the local system.

Bothered by the ugly way Xdebug stack traces were turing out, Derick Rethans has created a script to fix that.

I've always been annoyed by the way how Xdebug's stack traces looked liked. So I spend some time on making them look better. I will show the differences according to the following script.

The simple script takes the output and adds a bit of formatting, stripping down the information to make it a bit more clear. Check out the before and after shots to see the difference.