Dmitry Mamontov has posted the second part of his "How to Create a PHP C Extension to Manipulate Arrays" series on PHPClasses, building on part one and adding in the ArrayAccess and Traversable interface functionality.

In the first part of this article we learned how to create an extension for PHP written in C to create a class that works like arrays. However, to make the class objects really behave as arrays you need to implement certain interfaces in the class.

Read this article to learn how to make a PHP class defined by a C extension implement ArrayAccess and Traversable interfaces, as well understand how to solve problems that you may encounter that can make your extension slower than you expect.

He takes the class he defined in part one and walks you through the addition of the two interfaces. He shows you where they're defined in the PHP source, what the code looks like and how they integrate with the class. He also shows you how to customize the object class handlers, making it possible to use the custom class (object) as an array. Adding Traversable is easier, adding an iterator return method that allows for the data internal to the class to be iterated through.

The PHPClasses.org site has posted a book review of Paul Jones' "Modernizing Legacy Applications" ebook today covering some of the content in the book and the reviewers own personal opinions on what was good and what could use improvement.

The current technologies we have today and the numerous improvements to the PHP programming language, makes our legacy applications operate "below today’s standards". They need to be improved or rewritten, but who would want to rewrite an application of many thousands or millions of lines of code?

That’s why you should read this book, ‘Modernizing Legacy Applications in PHP’ by Paul M. Jones. It explains the nitty-gritty of how PHP applications were built over a decade ago and why they are now called legacy applications. He explains why your legacy applications are not meant to be rewritten, but optimized and improved to support today’s standards.

The reviewer goes through each chapter of the book, giving an overview of each including topics discussed and a few of the handy tips. Overall he recommends the book not only to those experienced in the industry but also those new to developing in PHP, helping to prevent bad behaviors before they start.

In his latest post Phil Sturgeon talks about a project that's been running for a while, the The League of Extraordinary Packages and aims to clear up some recent misconceptions about the group and what they strive for in the projects they endorse.

This is the story of group of friends, who decided to write some code, but somehow confused and angered everyone with a keyboard. [...] Where should I release this code [I was super excited about releasing]? Should I release it with a vendor name of Sturgeon? That seemed rather egotistical. I could make something up, but what is the point of a single vendor with a single package? I wondered if any of my buddies were having this problem. [...] Being as hungover as I was, I thought long and hard, for about 5 seconds until something amazing happened in my brain... The PHP Super Best Friends Club! The guys loved it, and we started making plans immediately.

He goes on to talk about The League and some of the goals of the organization including the stated desire for quality code and a constant stream of work on the project (no abandoned or stale projects). He talks about how some of the rules for inclusion were created and some of the members of the various projects it includes. He then gets to the "recent misunderstanding" part of things with the clash of the League and the PHP-FIG (see here). He clears up some of the confusion in that thread by stating that:

• League != PHPClasses
• League != PEAR

He finishes off the post talking some about the leadership of the group (hint: it's an organization, not really run by a person or persons) and some of the work he's doing to ensure the future of the League and the packages it includes.

On the PHPClasses.org site today Manuel Lemos has released the latest episode in their "Lately in PHP" podcast series: Episode #48 - To TDD or Not TDD?.

Lately the debate about whether you should use TDD or not in all software projects all the time has been very intense. [...] They also talked about the upcoming end of life release of PHP 5.3, getting information of parameter type hinting with reflection, using object methods on native data types, security problems of OAuth implementations, and the built-in support of Composer to access password protected repositories.

You can listen to this latest episode either through the in-page audio player, by downloading the mp3 or you can watch the live recording over on the PHPClasses YouTube playlist. A transcription of the recording is also provided as well as links to some of the topics mentioned.

The PHPClasses.org site has released the latest episode of their "Lately in PHP" podcast series today - Episode #47: PHP is the Best Competitor of PHP.

PHP developments gained new life thanks mostly to Facebook Hack language and Zend reaction with PHPNG. Since Facebook Hack is mostly a fork of PHP, it seems PHP is the main competitor of PHP. These developments were one of the main topics discussed by Manuel Lemos and Michael Kimsal in the episode 47 of the Lately in PHP podcast. They also discussed new proposals for the next PHP versions like negative string offsets, offsets to Reset() and End(), a mail handling interface similar to session handlers, error handling in PHP.next, and return type hinting declarations.

You can listen to this latest episode in one of a few ways: either using the in-page audio player, by downloading the mp3 or by watching the live recording of the episode on YouTube.

In the latest episode (#46) of the "Lately in PHP" podcast series Manuel Lemos and Arturs Sosins wonder if Hack will ever replace PHP.

The release of the Facebook Hack language has shaken the PHP community since it implements several frequently requested features that were never implemented, many users are considering to drop PHP in favor of Hack. This was one of the main topics discussed by Manuel Lemos and Arturs Sosins on the episode 46 of the Lately in PHP podcast. They also talked about the OpenSSL Heartbleed security bug may affect PHP sites or not, ideas for the PHP 6 engine, the need for an official PHP specification, and an advanced email validation that can provide suggestions for address typos like Google did you mean feature.

You can catch this latest episode either through the in-page audio player, by downloading the mp3 or by watching the video of the live Google Hangout recording.

The latest episode of the "Lately in PHP" podcast series has been released by PHPClasses.org today - Episode 45, "The Security of Future PHP Versions".

As the plans for the upcoming PHP 5.6 and PHP 6 versions are being finalized, some of the proposals are about improving the security of these future PHP versions. That has been one of the main topics discussed by Manuel Lemos and César Rodas on the episode 45 of the Lately in PHP podcast. They also have talked about several other types of proposals and ideas for PHP 6, as well a tutorial on How to Use a Webcam to take Pictures in PHP Application.

You can listen to this latest episode in a few ways - either through the in-page audio player, by downloading the mp3 or you can watch the live recording over on YouTube.

The PHPClasses.org site has posted their latest "Lately in PHP" episode - #44, "The Debate About All PHP Frameworks that Suck".

The video and the article about when Rasmus Lerdorf stated that in his opinion all PHP frameworks suck had great reprecussion. In this podcast the debate about reasons for this opinion continued with Manuel Lemos, Cesar Rodas and Yasir Siddiqui, the winner of PHP Innovation Award edition of 2013.

They also talked about the the Uniter PHP interpreter written in JavaScript, plans to remove the MySQL and IMAP extension in PHP 5.6, whether the next major PHP version should be PHP 6 or PHP 7.

You can listen to this latest episode either through the in-page player, by downloading the audio or watching the video of the live recording.

In a recent post to his site Matthias Noback looks at what he sees as the future of packages in PHP including some thoughts about the offerings on PHPClasses.org and the rise of Composer/Packagist.

When you ask me: what is the reason for a PHP developer to write classes? I answer: in order to separate responsibilities and hide data. Many principles have been devised to help developers fulfilling these tasks. But in most cases there was no sign of these principles underlying the code on phpclasses.org. This is why many people have turned their back on phpclasses.org. I was about to do the same. But in response to my tweet some people, including Manuel Lemos, responded that everybody needs a place to learn and try.

He looked a bit more into the PHPClasses site and found some new features not known about (including Composer support). He points out some issues with their approach about publishing packages and how they're released. He contrasts this with how Packagist.org handles the Composer information and package statistics. He looks at some recommended ways to judge the quality of packages and mentions a new book he's writing to help PHP developers create better, more useful (and flexible) packages.

On the PHPClasses.org site today Manuel Lemos has a new post showing how you can use Composer in your deployments to help install packages from the PHPClasses site.

You can install one or more packages from PHP Classes, JS Classes or other Composer repository sites. [...] To make it simpler for you, PHP Classes and JS Classes generate a sample composer.json file for each package available in the Composer repository. Just go in the page of the package you want to install and click on the Install with Composer link.

He includes a brief guide on installing Composer and an example of the resulting "composer.json" file when you click on a link in a package. He points out the use of logins (depends on the package maintainer) and the use of an "auth.json" to automatically provide this information.

This is a great example of how a site that puts the Composer ecosystem to work to provide packages outside of Packagist. Composer, by default, relies on Packagist for its package information, but you can provide alternate repositories too - including using something like Satis for local packages.