dikini.net - php

php closures and lambda functions rfc

vlado — Fri, 20 Jun 2008 06:45:44 -0400

There is a discussion going on in php land about introducing closures and lambda functions, there was even a discussion on haskell-cafe about it (chx strikes again ;). About time, I would say. Having this functionality is a bonus. Having it implemented badly or half-arsed is going to do more damage than help. This is a short summary of what do I understand from the rfc and what do I think about it.

drupal 5.0 beta

vlado — Wed, 01 Nov 2006 08:40:44 -0500

Sweet. Really. There are not too many big changes, but funnily enough they are felt more than previous betas/pre-releases.

First you are struck with the really nice, simple, stylish, cute, add your own epithet default theme - Garland. You can modify the colour scheme online. So palette builders enjoy and share.

Kudos to the reorganised admin pages and everyone involved in that. At first glance it is allright.

The infamous cck and views leave a lot of traces in core.

All I can say it took me between 5 and 10 minutes to setup a basic group blog site. That includes database creation magic, (php) file uploads, user registration ...

Time for theming, upgrading and code porting I suppose. Just where could I get it from?

Models, records, databases, friends and foes

vlado — Fri, 27 Oct 2006 11:01:12 -0400

the beginnings of a long on DB related pattern discussion.

First sketches

vlado — Fri, 27 Oct 2006 10:57:32 -0400

Ok, Let's recap:

Relational database (SQL) tables are records. We can view them (in our heads) as record type definitions.
JOINS define (some kind of) derived union types.
SQL CROSS JOINS are full cartesian products, i.e. union types where no name folding/aliasing is done by the imaginary type system

How can we model that in php?

Classes (and objects) are records. Arrays are records too. Both are candidates for doing the job. We need to be able to somehow represent this (meta) type information and manipulate it. The aim is to have a natural feeling/looking abstraction of the database in php. It should be flexible enough, for us to modify the relations at runtime, as we need. It should allow us in the long run to have a near optimal speed and not too much complications in the end code. That is a tough cookie.

Problems of active record and friends

vlado — Fri, 27 Oct 2006 06:25:45 -0400

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!

A catalogue of php design pattern shorts

vlado — Fri, 27 Oct 2006 05:57:36 -0400

What can you find on these pages?

A pattern catalogue with php pseudo-codish examples. For working implementations you can always check what the kitty thinks of that. I might have problems with over implementation, but those are my problems, it does not mean those pages are notr worth as a reference.

Why?

A reminder and a tantrum space

Why have you moved the catalogue to this page?

Because I wanted to separate this catalogue from longer descriptions I plan to put, and all of them should live under design patterns

Warnings and notices

warning I realised, late enough not to correct it, that I'm using a particular case of wishful thinking - using any php callable in $callable(...) expressions. The reality is abit uglier. We need to use either call_user_func($callable,...); call_user_func_array($callable,...) How I wish php could do that out of the box, especially when it actually does it, just not in the short syntax. Anyone happy to hold my hand to do a php patch for that feature? I'm very unfamiliar with the internals, sorry.

notice As Jared notes in his comment calling functions/methods with $ in a lot of cases you can use $obj->$meth(...) instead of call_user_func($callable,...);. Indeed you can use the following code as part of the remedy list($object,$method) = some_call() $object->$method(...) unfortunately this discriminates against functions, which are lighter to use than their method brethren

and a mention The above two used to live on the top pattern page until I moved them here

macro processor - initial notes

vlado — Wed, 30 Aug 2006 05:46:40 -0400

Most of my work on this is on paper, and some code sketeches. There quite a few non-trivial issues, and hard decisions to be made. Since I have the knack of loosing or recycling the various paper bits lying around, I decided to keep at least some of them in my diary, aka this blog.

initial requirements

convenient syntax and semantics: convenience matters. The syntax should be obvious. The meaning of the syntax should be easy to grasp.
minimal core: the core of the macro processor should be minimal. This will help managing the code quality. The minimal core should be enriched using macros.
retargetable/multi-targets: using one and the same 'surface syntax' to produce different target code. It should be possible to have a one to many code generation. Example application - one definition producing javascript, php and sql code. Alternative example: one definition - three code targets - debug, deployment + a set of autogenerated tests
target and syntax agnostic: no assumptions should be made (at least at top level) about the target or syntax. We should be able to accomodate any theoretically parsable syntax, within reason, of course. Subject to parsing strategy selection, etc...

macros, higher-order functions, datatypes and design patterns

vlado — Tue, 29 Aug 2006 10:09:21 -0400

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.

SOC: Collaborative Editor, pimping for tests and comments

vlado — Thu, 17 Aug 2006 10:56:58 -0400

Ernest has done quite a lot of experiments with his collaborative editor. Early on I've advised him early on to focus on the communication/collision detetection/... part as opposed to a new really fancy editor. In the ideal world his code should be mixed in with and editor of your choice, but that is a utopian fantasy.

At the moment the demo code is focused around a special node, but Ernest is working on removing the specialisation to eventually handle any form.

If you are reading this please try it (links follow) and give him comments, ideas, etc... Don't kill him though - the learning curve of the drupal apis is steepish. Help with ideas and bug reports works better.

the drupal groups page
how to test the module page a bit outdated, but the major points still valid (hint: look for the usernames)

Rewriting macros - the peculiar case of php

vlado — Wed, 16 Aug 2006 08:29:03 -0400

Without going into theoretical details, some of which are quite alien to me, I'll try to describe some of the challenges that pattern patching rewriting macros might pose for a language like php. After brief explanation what kind of a beast is this, I try to explore some of the finer points, which might cause problems. The intent of this post is to sketch a design and highlight some of the possible issues.

nested classes and other beasts

vlado — Fri, 11 Aug 2006 05:35:25 -0400

It seems I'm not alone in not wanting added complexity in php.

So what? I would rather the core developers spend more time implementing Namespaces than some feature no one in their right mind would use. People would use Namespaces and people advocating subclasses can use Namespaces for such a feature.
Don’t Advocate Subclasses (Inner Classes) - SantosJ

From a 'theoretical' perspective php is weird. Really strange. It has some low(ish) level features, for example the semantics of a function, the lack of nested functions and closures, as well as high level ones - the runtime symbol resolution, .i.e. variable variables and the $$func() syntax.

out of the (php) loop

vlado — Wed, 09 Aug 2006 12:32:03 -0400

inspired by Verity , my urge to display my writing talent and random buzz on the internet

This conversation was (allegedly) overheard in a nursery, which won't be disclosed to avoid litigation

Write a standard php loop on the nursery blackboard

Come on, can't be bothered. Are you joking?
foreach( $array as $key => $value ) echo "$key $value";

Wrong! Don't you ever learn proper language usage

What have I done NOW?

Poor man's macro programming in php (revisited)

vlado — Tue, 01 Aug 2006 04:31:59 -0400

How exactly can you do macros in php now?

Macros have (let's say) two main responsibilities - adding syntactic sugar and abstraction of common patterns. The syntactic sugar bit is something which probably should happen at compile time, at least in a weakly typed language like php. So I'll skip them. The abstraction of computation, well this is wat codified design patterns are. This is what function, classes and the rest of the things we read about and use usually do. To abstract a function in php there are at least two different strategies, probably more, but these two are effective in diametrically different situations. The first one is a combination of the ideas of generic functions (higher order functions) and partial evaluation. In code it can look something like:

Proxy

vlado — Thu, 27 Jul 2006 11:20:04 -0400

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

Accumulator passing

vlado — Thu, 27 Jul 2006 10:59:21 -0400

Intent

Use of an accumulator variable to allow the finer control over the assembly of the final result of an algorithm

Motivation

We want to use method-chaining, but we need to return values from some of the methods

Implementation

Use an accumulator variable

Example

a simple IFS( iterative function system )
x(t+1) = x(t) + f[random(1..i)]( 1/(t+1) )
note: the implementation is quite naive and not foolproof at all.

<php
class example {
  private $ifs = array( 'sin', 'cos' );  

  function x( &$acc ) {
    $acc['t'] += 1;
    $acc['x'] = $acc['x'] + $this->ifs[ rand(0,1) ]( 1/ $acc['t'] );
    return $this;
  }
}

$ex = new example();

$something = array('t'=>0, 'x' => 0 );
$ex->x($something) -> x($something) -> x($something);
print 't: ' . $something['t'] . ' x: ' . $something['x'] . "\n";
?>

and when you run it:

vlado@cow:~/php design patterns$ php  php accumulator_passing.php
t: 3 x:1.34692254127
vlado@cow:~/php design patterns$ php accumulator_passing.php
t: 3 x: 1.64809122021
vlado@cow:~/php design patterns$ php accumulator_passing.php
t: 3 x: 2.66401049301

Fluent Interfaces/ Method chaining

vlado — Thu, 27 Jul 2006 07:33:18 -0400

Intent: return the next context of computation, enable simple and flexible sequencing of computation
Motivation: We want to provide a small domain specific language to improve the readability of the code
Implementation: return the next expected object (state)
Examples: class fluent_class { var $state_var; function self_next( $arg ) { .... return $this; } function other_next( $arg ) { .... return $this->another; } } $obj = new fluent_class(); $obj->self_next(1) ->self_next(2) ->other_next(3) ->something_else(4);
Note: This is an awkward idea to explain in words. Essentially you are delegating the desision what is the next object in the chain to the executable methods. It probably should be combined with weaving the values, which we would otherwise return, using accumulator style passing, or some other store method.; Have a look at Jonnay's post for better and more sensible code examples and the Fluenter class.; I sometimes look at this as the imperative "version" of continuation passing, but let's not even get there.

Poor man's macro programming in php

vlado — Wed, 26 Jul 2006 11:43:44 -0400

Jonnay's post I mentioned before started me thinking - what do you need to have macros in php. What is the closest we can get to that without actually changing anything in php (poor man's version? What minimal sugar does php need to make it comfy? What is the natural syntax for macros in php? I definitely don't know the answers to these questions but let's try:


  macro delay() {
     match { delay( $func, ... ) } : 
       { $varname = $func . random();
         $$varname = array(new promise( $func, ... ), 'evaluate'); 
         return $varname;
       }
     match { $func( ... ) } :
       { return call_user_func($$varname, ... }; }
  }

This looks kind of allright, phpish. It has problems, but the above dream code demonstrates the idea enough - match the left-hand-side code and substitute it with the right hand side. The difference from C macros is that this macro is a program fragment/function/..., the result of which is substituted in the AST, as opposed to simple string pattern matching + substitution

Googles Summer of yawn.

vlado — Wed, 26 Jul 2006 09:07:08 -0400

Googles Summer of yawn. - Google's "Summer of Code" has started and they have announced a few PHP projects. Some of them look interesting and useful. However, I am going to pick apart one in particular, that to be honest, looks neither interesting or useful: The PHP Macro Preprocessor.
....

Why does the PHP Preprocessor need to be stuck in a world of #ifdefs and #includes? Instead of blindly copying what the C preprocessor does, why not focus on the languages strengths and deficiencies? The object system of PHP needs to be looked at, and see if it can be improved upon through a method of code transformation.

[sacrificial rabbit]

I sooo totally agree with Jonnay on this. In fact it is simply like reading my own thoughts, just put it better english, , ok, nearly. But what to do about it? I don't really know, I'm afraid I chicken out from digging into the guts of php. When I last looked there it was really scary.

Updated design pattern collection

vlado — Wed, 26 Jul 2006 06:22:18 -0400

I guess I'm on the down form my design pattern tantrum hit. I updated the collection so it now has about 20 of them, not all can be considered "officially" design patterns, but to be honest I don't really care. I'm very well aware that I ignore the existance of boundaries between design patterns, idioms, techniques, ... That is intentional. I like my rainbow coloured world and I want to keep it that way. If you disagree - just read the small script. My tanrum energy is over and I need to do work work. So the combing over the php design pattern collection will come later. For now enjoy, and have anger fits of your own.

Oh yes. I'm using a particular case of wishful thinking - using any php callable in $callable(...) expressions. The reality is a bit uglier. We need to use either call_user_func($callable,...); call_user_func_array($callable,...) How I wish php could do that out of the box, especially when it actually does it, just not in the short syntax. Anyone happy to hold my hand to do a php patch for that feature? I'm very unfamiliar with the internals, sorry.

Coroutines (generator based)

vlado — Wed, 26 Jul 2006 05:50:22 -0400

Intent: Abstract out naturally parrallel evaluation
Motivation: Merge two functional streams
Implementation: The coroutines can be implemented using generators. The example shows an example application
Examples: //if gen and gen2 are generators function merge_data() { try { do { $data[] = 10*gen() + 5 + 4*gen2(); ... } while( some_condition( ... ) ); } catch ( $e ) { .... } return $data; }

Generator (iterator protocol based)

vlado — Wed, 26 Jul 2006 05:46:42 -0400

Intent: Define a (stream like) value producer
Motivation: We want to be able do define functional streams
Implementation: Any object implementing an iteration protocol (interface) can be a base for a generator.
Examples: //a generator implemented with iterators function generator($it=null, $cb=null) { static $itor; static $callback; if(!isset($itor)) ($itor = $it; $callback=$cb; } if($valid()) { $out = $callback($current); $next(); return $out; } //or if you are not sure about the type of the above callables ($valid, $next,..) if( call_user_func($valid) ) { $out = call_user_func( $callback, $current); call_user_func( $next ); return $out; } else throw( new some_exception ); }

Iterator (based on protocol method)

vlado — Wed, 26 Jul 2006 05:31:04 -0400

Intent: Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
Motivation: We want to be able to postpone the effects of a computation, for example delay printing from a function to webserver output until whole web-page is assembled
Implementation: This is an alternative implementation based on protocol method, rather than interfaces
Examples: class alt_iterator { private $st = array(); function next() { ... } function current() { ... } function valid() { ... } //... put the rest here function protocol() { return array( array($this,'next'), array($this,'current'), array($this,'valid'), ..... ); } } //an example use function do_them($itor, $callback ) { list($next, $current, $valid, ...) = $itor->protocol(); while($valid) { $callback( $current ); $next(); } }

Dynamic dispatch

vlado — Wed, 26 Jul 2006 05:23:19 -0400

Intent: dispatch the control based on the environment, but delay enumerating the cases
Motivation: we don't know at the time of writing the code what are the different cases to dispatch on
Implementation: (nearly) invisible in php
Examples: $case($arg); $object->$method($arg); call_user_func($calleable, $arg1, $arg2);
Note: A more elaborate form of dynamic dispatch is Method Chaining

Lazy evaluation

vlado — Wed, 26 Jul 2006 05:10:57 -0400

Intent: A function/method call results in a promise for future computation
Motivation: We want to be able to postpone the effects of a computation, for example delay printing from a function to webserver output until whole web-page is assembled
Implementation: Instead of evaluating a function, we deliver a promise - a callable with no arguments, which when forced is executed
Examples: //for simplicity handle only functions with one argument class promise { private $args = null; private $func = null; function __construct($func, $args) { $this->func = $func; $this->args = $args; } function evaluate() { call_user_func($this->func,$this->args); } } function delay( $func, $arg ) { return array(new promise($func, $arg), 'evaluate'); } //example use ... $chunks[] = delay('a_printer',$a_variable); ... foreach($chunks as $chunk ) { if(is_callable($chunk)) { $chunk(); //force - this does it's own printing in this example } else { print $chunk; } }

Nested scope

vlado — Wed, 26 Jul 2006 04:46:50 -0400

Intent

Create a composable runtime hierarchy of data and behaviour

Motivation

We want dynamic means of modifying complex runtime structures

Implementation

Use php magic to dynamically dispatch requests to parent methods

Examples


class scope {
  var $parent;
  function __call( $name ) {
    if(isset($parent[$name]) { return $parent[$name](); }
    throw( new someException() );
  }

  function let( $name, $value ) {
    if(is_object($value)) { 
      //hygiene
      if(isset($this->$name)) { $this->$name->parent = null; }
      $this->$name = $value;
      $this->$name->parent = $this;
  }
}

//alternative let
function let($parent, $name, $class) {
  $parent->$name = new $class();
  $parent->$name->parent = array($parent,$name);
}

?>

Notes

A concept related to and very often mistaken (mixed) (by me) with (for) closures
the let method can be folded into __set if we want this behaviour to the default for assignments to object fields

Closure

vlado — Wed, 26 Jul 2006 04:29:49 -0400

Intent: Create first class behaviours capable of storing state between use
Motivation: We want to maintain the history of computation, an maybe save and reuse the computation at a particular point in time
Implementation: The basic implementation is invisible in php - static variables in functions (but that doesn't allow us to have the usual features of a language with closures because functions in php are not first class objects, i.e we can't copy them), objects (they get us there, albeit more verbously). The examples below are borrowed from io-reader: php closures. Read the post and the full code to understand the full implementation.
Example: // fixed-point combinator function Y(Lambda &$le) { return lambda(get_defined_vars(), 'Lambda $f', ' return $f->call($f); ')->call(lambda(get_defined_vars(), 'Lambda $f', ' return $le->call(lambda(get_defined_vars(), \'$x\', \' return $f->call($f)->call($x); \')); ')); }
Note: Closures and objects are dual, compare behaviour with state and state with behaviours
Yet another note:: Alternatively have a look at this implementation or my emulating closures in php blurb
Final note:: All this is better avoided in php - too many underwater rocks

State

vlado — Tue, 25 Jul 2006 12:41:07 -0400

Intent: Allow an object to alter its behavior when its internal state changes.
Motivation: An article in a typical editorial workflow exibits different behaviours in different publication stages. We want an object that hides the complex logic.
Implementation: Similar to the strategy pattern. Need to handle state change and behaviour change.
Examples: $new_state="edit"; $new_protocol="edit"; //change the behaviour list($view,$update,$get, $set) = $object->protocol($new_protocol);
Related patterns: Protocol Method, Builder, Strategy
Note: Too many different implementations exists. This means that there is probably a need to clean up the intent.

Observer

vlado — Tue, 25 Jul 2006 07:54:56 -0400

Intent: When an object changes, notify all interested parties
Motivation: events, synchronisation, ...
Implementation: Use hooks pattern at and after to implement the observer; No implementation needed in the Subject class
Example: //initialisation $hs = new hooks(); $observer = new interested_party(); $change_method = array($object, 'setter'); //setup change point(can be done externally from $change method) $hs->at('change', $change_method); //express interest $hs->after('change', array($obesrver, 'callback')); $hs->run($arg);
Note: The precise implementation of the hooks may differ, depending on functionality, abstraction, sugar, ... Have a look at the drupal hooks as well.

Hooks

vlado — Tue, 25 Jul 2006 07:41:04 -0400

Intent: Build a function/method from multiple components
Motivation: Very often we need to decouple or delay definitions until run time
Implementation: Implement a methods that allows executing a set of functions at predefined times
Example: class hooks { private $cache = array(); function run( $func, $arg ) { foreach(array('before','at','after') as $hook) foreach($this->cache[$func][$hook] as $f) { $f($arg); } } function hook($hook, $func, $cb) { $this->cache[$func][$hook][]=$cb } function before($func, $cb) { $this->cache[$func]['before'][]=$cb } function at($func, $cb) { $this->cache[$func]['at'][]=$cb } function after($func, $cb) { $this->cache[$func]['after'][]=$cb } function around($hook, $func, $cb) { $this->cache[$func]['around'][]=$cb $this->cache[$func]['after'][]=$cb } } //and usage $hs = new hooks(); $hs->hook('before','label','before_a_func'); $hs->hook('at','label','core'); $hs->run(); //or using the individual methods $hs = new combinator(); $hs->before('label','before_a_func'); $hs->around('label','tracer'); $hs->run();

Dynamic loading

vlado — Tue, 25 Jul 2006 07:21:47 -0400

Intent

Keep working set small and mainatin fast start time by loading features as required

Implementation

use __autoload()

Example

function autoload( $classname) {
  list($path,$file) = loadpath( $classname );
  require_once "$path/$file";
}

Notes

we are loading a file, based on some conventions interpreted in loadpath
This can be used to implement module-like system, but the lack of subclasses or similar tools makes the 'module' bindings always transparent