Your concept looks interesting. However, I don’t understand why you use the array syntax to create the hobbies in your example. Wouldn’t it be more logical to use something like:

echo Person::create(array(
    'name' => 'taylor luk';
    'hobbies' => array(
      Hobby::create(array('title' => 'swimming')),
      Hobby::create(array('title' => 'watch tv'))
    )
))

can easily expand to other features..

* single table inheritance
* class table inheritance if someone is up for challenge

* static methods (class methods) used for table (collection) wide operations, new record, find
* instance method use for row specific operation, delete, update

Well that requires to get static property and methods inheritance happening, some of the tricks i have included in this project i was contributing, that including fixing the late-static binding for PHP 5.1 and 5.2

I have build a semi-prototype code demonstration the concept on how to make it possible to do a ActiveRecord-like base class with better static method inheritance in PHP 5.1 +

Concept + demo code

http://gist.github.com/88016

a project i contributing (rubyism in php + magic)

https://github.com/speedmax/phuby/tree

I think the clone method is a “nice-to-have” feature, it is not essential but in certain situations it can allow you to write cleaner code.

IMO, I will not change the default behaviors that Cake does. Such as Model::find() returning array datas by default and the associations eager loading. So I’m prefer to give the users a choice and make sure they know what they are getting. Another reason, I use the bake command quite often for baking a quick admin interface, and the default baked codes will not working if returning an object.I don’t want to give the users to much “surprises” by the error notices.

About the clone method, I just designed it for enabling users to add some alike data in a quick way. I’m not sure if this method is necessary.

I’m wondering about two things: is the enableActiveRecord() really necessary? I mean, if you add the ActiceRecord behavior then you probably want to use it, so I would enable it by default.

The other point is the clone() method. I think it shouldn’t allow parameters, as cloning is about creating an identical object. Or maybe the method should be named differently.

But all in all it looks very promising!

I would like to hear some comments about this stuff:
http://pastie.caboo.se/200932

public static function findAll() {
    // this method is used like Post::findAll()
}

$posts = Post::findAll();

And have each of the $posts be an instance of Post. That way, the logic is separate, but it’s still all contained within the same class.

@Tim: In retrospect I think the example in the article is not that good ;-) I agree with you that it doesn’t make much sense to create an object simply to call delete() on it. In such a situation it would be easier to call delete() at the table level. On the other hand there are also situations when it is more natural to call delete() on a record object. In the end it is up to the developer to choose the “right” method.