The moment you start writing code that grows beyond a few classes, you start to realise that you need a way to group files and logic. While this is easy to do, it can become quite difficult to ensure that you have class names that are unique and don't end up accidentally clashing with other classes in your own code, or classes in other people's code that you are using.

He talks about PHP's namespacing, a relatively recent addition, and how pre-5.3 "pseudo-namespacing" was done through class and directory names with autoloading. He compares this to Ruby's module support that provides a sort of built in namespacing support. He includes a multiple namespace Ruby example and shows how to nest modules for even more fine-grained separation.

In another entry in his "Confessions of a Converted PHP Developer" series Mal Curtis about a typical class development path PHP developers take and how it can be a limiting, linear progression from one step to another.

In converting to Ruby I realized how strict PHP is in its class hierarchy. This surprised me as I'd always viewed PHP as a very loose language, mainly due to its loose typing and lack of formal code structure guidelines. [...] I find most PHP developers learn starting by using inline PHP as a low learning curve entry point into dynamic web languages and then move on to fuller, more complex, applications.

He includes a few code samples comparing how Ruby, while still allowing the same kind of structure, also lets you redefine classes on the fly. His example shows redefining a method in a Ruby class using a method commonly called "monkey patching". It's good that he points out a downfall of the approach too:

I must note that Monkey Patching is often a quick fix solution that can create headaches for future developers (or for yourself, if your memory is like mine) for several reasons. [...] Use at your own risk!

There's several different articles all over the web talking about the "monkey patching" approach and if it's possible/useful in PHP.

From RubySource.com there's a new post from a confessed developer who moved from PHP to Ruby about PHP's private visibility rules and how they compare to Ruby's.

Alright class - today I’m here to talk about the differences and similarities that PHP and Ruby have when it comes to object properties, methods, and their visibility - how you create variables inside classes, and how you can interact with them.

He compares the private properties in PHP classes to the corresponding handling in Ruby, including the getters and setters to go with them. There's also a look at class visibility settings in Ruby.

On RubySource.com there's a recent post with a bit of a confession from an ex-PHP developer who's moved over to Ruby about some of he is experiences in making the shift and why he's a convert now.

I’ve been a PHP developer for nearly a decade, and in January this year I started developing in Ruby. While initially a sceptic, I’m now a convert - and I’m here to share my experiences with you. [...] I’d like to think of myself as a fairly good PHP developer, and the idea of moving to Rails was both scary and exciting. [...] In Ruby’s defence, these are frustrations that are well made up for with the delights of finding out how easy other things are to do - and any learning process has its frustrations.

He compares a bit of code that would take a list of email addresses and pull out the domain parts of each, grabbing only the unique ones. He includes some PHP code (using anonymous functions in PHP 5.3) to get the job done and compares it to the Ruby method that's a bit more fluid and readable. He talks about some of his frustrations during the learning process of creating code like this and includes his steps as he evolved through it.