Matthias Noback has posted about CQRS (Command Query Responsibility Segregation) on his site showing how to reduce coupling and let the "model(s) evolve" that tries to break down some of the perceived complexity around the design technique.

CQRS has some reputation issues. Mainly, people will feel that it's too complicated to apply in their current projects. It will often be considered over-engineering. I think CQRS is simply misunderstood, which is the reason many people will not choose it as a design technique.

[...] CQRS alone simply means that you're making a distinction between a model that is used for changing state, and a model that is used for querying state. In fact, there's often one model that accepts "write" operations (called "write model" or "command model") and multiple models that can be used to "read" information from (called "read models", or "query models").

He goes on to talk about the more common structure in applications, a single model that handles all of the usual CRUD operations rather than having it split up. He then moves on to the topic of coupling and reducing it through the use of read-only models. He shows examples of the code for these models as well as tips for dealing with inconsistent data.

This new post on Cormac's blog shows a little trick you can use to make "read-only" object variables with the help of the handy magic methods built in to PHP5.

You can create read-only object variables by using the "private" keyword and the __get() and __set() magic methods. [...] So now classWithReadOnlyVar::readOnlyVar is only settable from inside the class, but you can read it from anywhere.

His example code initially sets up the read-only variable as a property of the example class. The __get magic method is called to correctly fetch the value but the __set intercepts anything trying to change its value. This same sort of thing can be accomplished with the protected/private keywords in PHP5.

As Lukas Smith mentions, the latest alpha release for the PHP 5.3 series has been released - PHP 5.3alpha2.

Wow, after what feels like ages PHP 5.3.0alpha3 was just released. Originally we hoped to be able to release now intermediate releases every 2-3 weeks, this one took a good 2 months. Somehow this releases did its very best to stall itself. People that needed to work on things together by chance ended up being busy with other things and vacations in just the right order to make things impossible. Most of this was to be attributed to the namespace discussions, which climaxed in the backslash FUD campaign.

He notes that a stable release is probably looking good in Q1 of 2009 (with namespaces being the delaying factor). He also suggests something that could help make things a bit simpler in the future - making the internals@ mailing list read-only for anyone outside of core developers. A good bit of the confusion and bickering came from those outside the dev team and it didn't help the group come to a decision any earlier.

You can find the official release information for the alpha2 on the main PHP.net website.

Mikko Koppanen is back with a tip for users of the ImagickPixelIterator functionality of Imagick - it's not read-only after all.

A few days ago I got a help request from a user: "How do you change pixel color during the iteration with ImagickPixelIterator". My initial response was that ImagickPixelIterator is read-only. Well, I have to admit I was wrong. After searching trough ImageMagick docs I stumbled across an example and noticed that PixelIterator (and therefor ImagickPixelIterator) is not read-only after all.

He illustrates with a code example, one showing how to make the object from an image and how to update every second pixel to be black. Source and result images are also included.

Mikko Koppanen is back with a tip for users of the ImagickPixelIterator functionality of Imagick - it's not read-only after all.

A few days ago I got a help request from a user: "How do you change pixel color during the iteration with ImagickPixelIterator". My initial response was that ImagickPixelIterator is read-only. Well, I have to admit I was wrong. After searching trough ImageMagick docs I stumbled across an example and noticed that PixelIterator (and therefor ImagickPixelIterator) is not read-only after all.

He illustrates with a code example, one showing how to make the object from an image and how to update every second pixel to be black. Source and result images are also included.