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.

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.

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.

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.