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.
Jani Hartikainen has followed up on a post from David Otten about standard classes in PHP and how they provide the base for much of what the language does.
David Otton posted a short but thought-provoking post about stdClass, which many think is the "base class" all PHP classes automatically inherit from. I have to admit that I had this misconception as well. [...] This [difference in PHP from other OOP languages] presents some room for analysis in how things are handled in dynamic and static languages, and how those differences affect things...
Janitalks about dynamic and static typing in languages and how that effects the base types things are extended from as well as some of the benefits that having a standard base class affords developers.
David Otton has shared a discovery he's come across in his development - user-defined classes are not derived from stdClass.
Many OO languages have the concept of a single base class from which all other classes are explicitly or implicitly descended. For example, Ruby, Java and .NET all have Object. It's a very common belief that PHP implements stdClass as a base class for all objects, but this is in fact not the case.
He illustrates with a code example showing the results of calls to instanceof with a normal user class and one that extends the stdClass object.
Kevin Waterson has posted a new tutorial to the PHPro.org website today - a pretty comprehensive look at the DirectoryIterator in the Standard PHP Library (SPL).
SPL provides a standard set of interfaces for PHP5. The aim of SPL is to implement some efficient data access interfaces and classes for PHP. Functionally it is designed to traverse aggregate structures (anything you want to loop over). These may include arrays, database result sets, xml trees, directory listings or any list at all. Currently SPL deals with Iterators.
On the Ibuildings blog Ruud Albertstakes a look at iterators - what they are and how they're used (including the objects the SPL makes available).
Let's kickstart this blogpost by defining what an iterator actually is. According to wikipedia, an iterator is. A collection can pretty much be anything. The most obvious sources would be arrays, but other than that, iterations can be done over database resultsets, strings, datetime intervals, directories, file content and XML listings, to name a few.
He looks at the iterator interface that comes bundled in the SPL and how you can create a custom one to loop through your own data collection. He includes an example - a colorful string iterator that "pretties up" an HTML string with various colors.
Stefan Priebschrecently posted about his struggles with creating a custom coding started with the PHP_CodeSniffer package:
In CodeSniffer, a coding standard is basically represented by an empty class that extends PHP_CodeSniffer_Standards_CodingStandard. I could not get the CodeSniffer to find my coding standard, though, and found the documentation lacking about where to put it, how to name it, and how to refer to it in the --standard switch.
After an email to Greg Sherwood (developer of the package) Stefan figured out his issue and has shared the solution in this post (step by step).
Daniel O'Connor has posted a quick guide to customizing your installation of the PHP_CodeSniffer PEAR package to match the coding standard you'd like.
PHP_CodeSniffer is a PEAR package which detects potential coding problems and enforces your style guide. The default is the PEAR coding standard, but you can easily change that.
His method requires the creation of a custom "FooCodingStandard.php" (named whatever you'd like, of course) that contains a class/method defining the "sniffs" you'd like to use for your standard. Use "pfm" to make it into a package and install it to your system - you'll be all set.
On the Make Me Pulse blog, there's a look at PHP6's support of Unicode in the SPL (Standard PHP Library) TextIterator handler.
I've just install the last version of PHP6 dev and I've decided to test the famous new feature, the PHP Unicode Support. I will not explain new things about PHP6 or Unicode or TextIterator, it's just my discoveries test on this features.
He steps through the process he followed - enabling Unicode support, testing various output methods (including just an echo and using the TextIterator) as well as some of the manipulation methods (next/first/current) that can be used to get certain characters out of a string.
In a new blog post, Paul Jones looks at three aspects of coding style - line length, volume and density - and how different people have different assumptions as to what's "right".
When it comes to coding style, there are are various ideas about how you should write the individual lines of code. The usual argument is about "how long should a line of code be"? There's more to it than that, though. Developers should also take into account line volume ("number of lines") and line density ("instructions per line").
He mentions the PEAR style guide when talking about line length, reading code like and sentence in line volume/density and how the "shorter is better" concept can be pushed to its extreme limits taking code into the unreadable zone.
Raphael Stolt, in working on his component for the Zend Framework (based on the PHP_CodeSniffer PEAR package), pulled together all of the information Zend provides about their coding standards into one place.
Before jumping into the development of a Zend Framework coding standard for the PHP_CodeSniffer Pear package, I spent some time revisiting and compiling the available Zend Framework coding standards into a handy one-paged Pdf document.