In a post to his site Fabian Schmengler has shown how to use class_alias to prevent breakage while renaming or moving classes around in your application during refactoring.

Sometimes you want to rename a class or move it to a different namespace. But as soon as it is used anywhere outside the package, this is breaking backwards compatibility and should not be done lightheartedly.

Luckily there is a way in PHP to have both, the old class and the new class, while deprecating the old one: class_alias().

He then gets into the details of using this handy function to define the links between the files, necessary in two different places to prevent autoloading breakage. He also offers an alternative, making use of the "autoload.files" option in the Composer configuration (but this means adding each one to that list). He finishes the post by suggesting one more thing as you update your code: making it with an @deprecated annotation to help locate it later (and flag it in your IDE of choice).

A new project has been launched in the Laravel community to try to maintain some of the core Laravel components that have been deprecated by the framework - the Laravel Collective.

The Laravel Collective is a new Laravel community organization headed by Adam Engebretson and Tom Shafer. It’s primary goal is to help maintain the core Laravel components that have been deprecated by the framework. Currently the packages the Collective is taking over is HTML/Form and Annotations. They have a new site in the works which, when launched, will have complete documentation, team information, and more information on the packages. Until it’s launched you can check out their GitHub repository.

The full project hasn't launched yet, but if you're interested in becoming a part of it, you can sign up for their newsletter and get updates as they're posted.

On the Ibuildings techPortal today they've posted the latest podcast recording from the 2009 Dutch PHP Conference sessions, Paul Reinheimer's look at maintaining state with Ajax ("in an Asynchronous World").

This talk will examine the two greatest problems in Ajax development (except for that pesky browser issue): Exactly what that "Asynchronous" word means, what problems it creates, and how they can be effectively managed, next the YUI Browser History object will be examined, finally handing control of Ajax applications back to the user via their familiar back button.

You can listen to this new episode in one of two ways - either by using the in-page player or you can download the mp3 directly.

Shawn Straton has posted the second part of his look at code readability today. This time the focus is on the structure of the code - file structure, code layout, etc.

I've had the pleasure of maintaining a legacy application developed by people who were past deadline the second they had their assignment handed to them in the past and it can get really interesting rather quickly when you see how sloppy you can get when you are in such a hurry. Here are some guidelines I've given myself to ensure that the structure is correct at the end of the day.

Some of his suggestions include:

• Breaking larger files apart into smaller, easier to maintain pieces
• Correctly naming functions/variables/etc
• Tabbing/spacing in to indent code blocks
• Input validation and error checking should always be included

In his latest blog entry, Jeff Moore tries to dispel a rumor about PHP code that's been floating around for years now - that it's considered hard to maintain.

The technocrat, heavily invested in his own technical prowess, faced with successful yet technically inferior code experiences cognitive dissonance. The only thing to do is to belittle the successful, but surely offensive code. "I could write better code than this," he says, or "this code sucks," or "this is unmaintainable."

Unfortunately, what Jeff says about many programmer's first introduction to PHP is right - that they download a popular application to check it out. This code is not always, shall we say, stellar. Jeff also brings up the point that the "PHP doesn't scale" myth goes hand in hand with this. After all, the larger the application, the larger the code, right? And the larger the code, the less maintainable it is, right?

Of course not - there are wonderful large PHP applications that are as easy to jump into and add/modify functionality to and keep up to date as there are small. PHP has one major thing going for it - it's simple nature lets developers keep things simple, and simple is good.

In his latest blog entry, Jeff Moore tries to dispel a rumor about PHP code that's been floating around for years now - that it's considered hard to maintain.

The technocrat, heavily invested in his own technical prowess, faced with successful yet technically inferior code experiences cognitive dissonance. The only thing to do is to belittle the successful, but surely offensive code. "I could write better code than this," he says, or "this code sucks," or "this is unmaintainable."

Unfortunately, what Jeff says about many programmer's first introduction to PHP is right - that they download a popular application to check it out. This code is not always, shall we say, stellar. Jeff also brings up the point that the "PHP doesn't scale" myth goes hand in hand with this. After all, the larger the application, the larger the code, right? And the larger the code, the less maintainable it is, right?

Of course not - there are wonderful large PHP applications that are as easy to jump into and add/modify functionality to and keep up to date as there are small. PHP has one major thing going for it - it's simple nature lets developers keep things simple, and simple is good.