PEAR::DB_DataObject is great. I really like it. We don't use it at work, though; having gone for a slightly different route. This pattern should be applicable, however, quite nicely to DB_DataObject.

First, the database is set to associative fetching - our results come out as neat little arrays with fieldnames, so a $row = $db->query(/*blah*/)->fetchRow(); makes $row["id"], $row["field"], etc...


Configuration:

<?php
require_once 'DB.php';

$db = DB::connect("mysql://blah:blah@server/databaseName"); //Defined elsewhere
$db->setFetchMode( DB_FETCHMODE_ASSOC );


?>

Next, we have our core object.

<?php
class Core {


    /**
     * Process and extract values from an associative array.
     *
     * Improve performance and overload in child classes.
     *
     * @param   mixed[]    $array  Typically an assoc array from a DB::result->fetchRow.
     * @return  bool
     */
    public function updateFromArray($array) {
                
        if ( is_array($array) ) {

            $class = new ReflectionObject($this);
            $properties = $class->getProperties();

            for ($i = 0; $i < count($properties); $i++) {
                $prop_name = $properties[$i]->getName();

                if (array_key_exists($prop_name, $array)) {
                    $this->$prop_name = @$array[$prop_name];
                }
            }
        }

        return true;
    }
}
?>

So, when we do a query we can mash up everything nicely (assuming we don't have two tables with the same column names):

$sql = "SELECT * FROM table t JOIN table2 t2 ON t.table_id = t2.table_id";

$result = $db->query($sql);

while ($row = $result->fetchRow()) {
   $t = new Table();
   $t2 = new Table2();

   $t->updateFromArray($row);
   $t2->updateFromArray($row);

   //Do whatever you like with your objects...
}

... and our objects get efficiently populated with data in a single query.

The behind the scenes magic...

class Table extends DO_Table {
//Business logic
}

class Table2 extends DO_Table2 {
//Business logic
}

class DO_Table extends DB_DataObject {
     public $field;
}


class DO_Table extends DB_DataObject {
     public $field2;
}

class DB_DataObject extends Core {
     
}

Now... there's a few gotchas with this; which is why we don't use DB_DataObject - you can accidentally overwrite information you shouldn't from Core::updateFromArray();

There's no validation - you have to trust the array data you pass to the object.

You have to watch your 'specialist' doesn't do anything silly like Table::updateFromArray($_REQUEST);

You are limited to one row, one *type* of object - you couldn't join a table to itself and such.

I love http://www.ning.com/ - and I fell in love with chaining whole bunches of objects together.

class Foo {
    function transform() {
         //Some actual code
         return $this;
    }

    function transform2() {
         //Some actual code
         return $this;
    }

}

$f = new Foo();
$f->transform()->transform2()->transform();

Concise!

class Borg:
    __shared_state = {}
    def __init__(self):
        self.__dict__ = self.__shared_state

What a pythonic way to use Singleton. It uses shared-state
approach where you can actually have many instances as you want
but they all share the same state. See Alex's recipe.

>>> b = Borg()
>>> b.x = 1
>>> c = Borg()
>>> c.x
1

A nice visualization from Simon Wittber's recipe

from appuifw import *
import e32, random
from math import *

app.body = c = Canvas()
width, height =  c.size
freq = random.choice([25., 50., 100., 200., 400.])

for y in range(height):
    for x in range(width):
        z1 = sin(x/freq*1.7*pi)
        z2 = sin((x/3+y)/freq*1.5*pi)
        z3 = sin(y/freq*0.1*pi)

        z = abs(z1+z2+z3)*255
        c.point((x,y), (z,z/4,z*4))
c.text((5, height-12), u'Freq = %d' %freq, 0xffffff)

e32.ao_sleep(5)    # wait 5 sec then quit

See a screenshot here.