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.

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?

the beginnings of a long on DB related pattern discussion.

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.

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!

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

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...

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.

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)

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.