He lists five different pain points he discovered when trying to use the extension:

• Lack of a true Semaphore
• Undefined error handling
• Undefined behavior of sem_get()
• Cannot disable semaphore auto-releasing
• A semaphore may be deleted when other processes are waiting to acquire it

The semaphore extension provides a PHP-based wrapper for the System V IPC family of functions (including semaphores, shared memory and inter-process messaging).

Particularly since version 5.0, PHP has been copying many of Java features and practices of Java programmers. This means that if Java programmers practices tend to be bureacratic and less productive, PHP programmers that use those features or adopt those Java practices may also become less productive. This was one of the main topics discussed by Manuel Lemos and Michael Kimsal on the episode 29 of the Lately in PHP podcast.

There's also a bit of discussion about adding generics to PHP and using OAuth in PHP. You can listen to this latest episode either via the in-page player, by downloading the mp3 or by watching the video of the recording. You can also subscribe to their feed to get the latest in the podcast series.

There's been some talk about PHP 5.5.0 over the past couple of months even though it is barely on the horizon. The reason for this is that the PHP project has seen some increased levels of activity over the last two years since the dawn of PHP 5.4 and now in to the early twilight phase of PHP 5.5.0-dev. For those of you that haven't been following the internals mailing list I'm about to give you a quick test-drive and sneak-peak at PHP 5.5 using the latest 5.5.0-dev branch (which is still TBD).

Obviously, since the actual release of this version has yet to be determined, some of this may change over time. He gets into some of the major advancements and features that will be included like:

• the "finally" keyword
• list() support in foreach()
• the Password Hashing API
• generators
• a new property accessor syntax
• scalar type hints

Code samples are provided in some places to help make a bit more sense out of the example.

Recently there has been a rather heated and intense discussion on whether the PSR-0 autoloader "standard" should be included as part of the PHP core (in ext/spl to be exact). I've tried to stay out of the discussion and have successfully done so. Until today. I feel that there's something that's been missing to the discussion. So rather then posting this to the internals list, I feel it's better served by a blog post on the subject. So here's my take on it.

As mentioned, he's not in favor of the inclusion for three different reasons:

• It's inconsistent with current PHP functionality and would bias development one way or another
• It's not an actual standard, just a loosely defined practice based on functionality already in place
• There's noting for core to gain by adopting it and could cause problems trying to make things fit a one-size-fits-all solution.

The PHP community was reacting to Lukas Smith's "Interfacing the PHP world" for most of last weekend. [...] It's a pretty major propositon to start 'interfacing the PHP' world. Catch up on the conversation and let us know what you think.

Mitchell summarizes Lukas' thoughts into three points - interfaces in separate repositories, PHP frameworks not adopting 5.3 yet and the customization of method names/naming conventions across frameworks and tools. Another response to Lukas came from Herman Radtke with Lukas following up his original post with "Why Bother?"

It is in general true that you should strive for writing code as simple as possible (in length but in complexity too) to obtain an end result specified by a requirement or a user story. If there are two designs for a feature, almost always we would choose the simplest. This article takes a broader view on object-oriented programming, and ask the following question: What are the constructs we don't need in an object-oriented language? What we can take away without hampering our capabilities of building software?

He has a whole list of things that he thinks could be removed - "extra features" that wouldn't cause heartache if dropped including:

• instanceof
• break/continue
• protected subclassing scope
• if (conditional)
• switch (conditional chain)
• public (for fields)

So why do we need traits, anyway? PHP is a single inheritance language, meaning that each class can only extend one other. This allows us to build logical class hierarchies which extend functionality in a "vertical" way. [...] What we need is a means of re-using code other than simple inheritance. That's where traits come in. Traits are classes containing a collection of methods, usually relating to a particular behaviour.

He shares a way that you can mimic some of the functionality that traits would give you (full code is available here) with an abstract trait class, reflection and a "superclass" that's extended to pass off the requests to the correct child object.

A week after the release of the new plugin system, a lot of activity has taken place. More than 30 plugins were created, and 51 new releases were published on 27 different plugins. Based on the feedback I have received from the community, I have made some tweaks to the system.

These tweaks include a newly designed homepage, the inclusion of RSS feeds and a special URL to view the older wiki documentation for some plugins.

The second post describes more enhancements based on other feedback (on the previous post). Updates based on this information include an new "overview" field to describe the plugin, a download of the Markdown syntax to make the documentation conversion easier and a "stric mode" validation if you upload a PEAR package.

Unlike most of the reviews you get, I was specifically looking at code quality [of the CMSs]. not fuzzy does it look nice!

He looks at a whole list of them including: Tanslucis, Siteman, Pivot, jaf-cms, Guppy, Doop and CutePHP. Unfortunately, most of the news is bad - between badly structured code and mixes of HTML and PHP, there was almost nothing good in any of them.

As a language construct within PHP it would be very easy to do the same, but easier to learn and to use. Beside some keyword issues (the RFC uses "use" as keyword, but this will of course conflict with namespaces) I'm wondering what this will have an impact on reflection - the RFC stays unclear about this.

A trait is a free-floating chink of functionality that, instead of being confined to a class (or file) that has to be called on to use it, exists where the developer can use it from anywhere at any time. This helps solve some of the issues with single inheritance in PHP.