In a new post to his blog today Anthony Ferrara looks at the (heated) discussion that's popped up around having the PSR-0 autoloader standard included as a part of the PHP core. He gives his reasons (three of them) why he's not for the decision.

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.

In a new post to DZone.com today Mitchell Pronschinske responds to some comments that were made by Lukas Smith about working with interfaces in PHP and what he sees as an ideal "drop in" 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?"

On the Web Builder Zone, Giorgio Sironi has a few suggestions about things that aren't really needed in object-oriented development but seem to have found their way in none the less (most of them are in PHP too).

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)

In a new tutorial posted on the Zend Developer Zone today Steve Hollis looks at something several PHP developers have said they want to seen in the language - traits - and how, until then, you can use traits now (well, sort of).

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.

Two new posts on the Symfony blog talk about improvements to the framework's plugin system (as found in recent releases).

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.

A little while back, Alan Knowles wondered something that I'm sure has crosses the mind of every PHP developer out there, especially when they came across a particularly bad chunk of code - some people should need to apply for a license before releasing their PHP code out into the wild.

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.

On the Stubbles blog, Frank Kleine has pointed out a proposal from Stefan Marr to include functionality for traits in PHP.

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.

The latest version of the CodeIgniter framework has officially been released - version 1.6:

EllisLab is proud to announce the release of CodeIgniter 1.6, our open source web application framework. The release marks a new turn in the development of the framework, and has received considerable attention from both EllisLab developers and the community.

There's lots of new features in this new release including a Database Forge class, improvements to their Active Record implementation, an extendable Model class, and the addition of extendable Helpers.

You can find out more about the framework on the project's homepage or just head straight to the downloads section and grab the latest updates.

Ed Finkler has pointed out a handy resource for those trying to cope with using the UTF-8 support included in several of PHP's functions - this page on the Web Application Component Toolkit wiki.

This page is intended as a reference for functionality PHP provides which can either help with handling UTF-8 or should be regarded as a risk when used in conjunction with UTF-8 encoded strings. Further information can be found on the Internationalization (I18N) and Character Sets / Character Encoding Issues pages.

It talks about the "dangerous" functionality PHP has (issues that the language has in current functions) when using things like the PCRE extension, the string extension, the array methods, handling variables, the XML extensions (DOM and SAX), image manipulation, and URL parsing functionality.

In this post from Padraic Brady, he compares some of the tools that are available to Ruby developers to some of their counterparts (if they exist) in PHP.

Anyways, here's the pitch. I've been using Ruby for a year now and my pet peeves with PHP started getting a bit too much to comfortably endure. [...] I don't like developing web applications with Ruby, or that thing Rails. Whatever it is. It's a framework, right? So I'm on a splurge of writing PHP tools for the same things in cahoots with folk like Travis Swicegood.

Tools he mentions include Autotest, Mutation testing, Mocha, Rspec, Heckle and some of their PHP counterparts like parts in PHPUnit and the DomDocument functionality.