dikini.net

Continuing from parts one and two of these series of posts I'll stick to iterators for the time being. I'll make a quick overview of the php Iterator and IteratorAggregate interfaces. Then will derive a pair of Observable(Subject) and Observer interfaces as their mathematical duals by flipping the methods (arrows) around and see what comes about. In fact, this technique was used by the C# team to derive the Rx framework.

In this post I'll try to sketch a number of related ideas about working with sequential collections, all of them expressed in php. Enumerations, enumerables, interators, iteratees and their cousins have been tortured to death, but as Eric Meijer and his team working on LINQ and Rx frameworks for .net show, it pays off doing it systematically. I'll revisit the Iterator and Subject Observer design patterns and will derive them systematically from first principles.

In php iterators come handy for all kinds of work on sequences - usually using

foreach( $sequence in $key,$value) { ... }

The problem with foreach is that it is not composable, but there are a lot of functions and operations on iterators which are, at least in theory. I will try to show how to achieve composability by, first, composing the processing of each individual step and, later, by composing iterators. This can lead to easily reconfigurable applications and a more declarative style of programming.

After a lot of silence caused by lot's of work (good, my bills are happy) and a continuous diversion into scheme, haskell, dylan and other interesting languages, I'm back into php speaking land. Funny feeling that. So here comes the beginning of something I've been continuously rubbing my (leftovers of) brains against.

copout This is not php specific, but since it discusses frequent problems occuring in php apps, I've labeled it with as php related as well. Makes it easier maintaining the site you see.

I have a problem with active record as a pattern. It is a logical one. Essentially it turn a (SQL) database row into an object. The class of the object represents the SQL table or view. Of course you can add behaviour to those classes and objects, i.e. activating those records.

All that is nice and dandy, but when you start talking about relations and constructing dynamically queries and corresponding objects, we start hitting the limitations of what I will call from now on the naive active record.

The problem is not trivial at all. It boils down to how to make peace between the host language type system (for example classes) and the SQL's dynamic compound types - the relations expressed as SELECT variants for example. It gets even harder when we decide to reverse the direction, so that we actulally want to update the database. Yuk! As though somebody actually does that!

While reading, researching and experimenting for my macros project the terms in the title get mixed a lot. I'll try to summarise what is my understanding of a lot of the above. To be fair, most of these words are heavily overloaded with sometimes contradictory and or ovelapping meanings, so this short is only about my personal summary, no pretence for a general study or lit review.

Generic programming intuitevely corresponds to design patterns, or a tool to implement them. There should be a distinction between the functional or algorithmic side of the term and the structural or data (type) genericity.

Intent

Provide a surrogate or placeholder for another object to control access to it

Motivation

We want to provide a wrapper around a set of classes to unify their access protocols

Implementation

• Provide a wrap method
• intercept calls to the wraper object and forward them accordingly, may change the protocol

Example

class Fluenter
{
        private $obj;

        function __construct($obj)
        {
                $this->obj = $obj;
        }
        static function MakeFluent($obj)
        {
                if ($obj instanceof fluent)
                        return $obj;
                else
                        return new fluenter($obj);
        }
        function __call($method, $args)
        {
                $result = call_user_func_array(array($this->obj, $method), $args);
                if (is_null($result))
                        return $this;
                else if (is_object($result) and ($result instanceof $fluent))
                        return $result;
                else
                        throw new RuntimeException(
                                                "Fluent::__call called method $method ".
                                                "and expected a null return or a non-fluent object, ".
                                                "got (".gettype($return).") $return instead.");
        }
}

notes

• This code is an unaltered copy from Making Fluent Interfaces Readable in PHP, I hope Jonnay doesn't mind that
• You might want to check out fluent interfaces( method chaining) and accumulator passing