Actions
This is for John, mainly, but anyone else read on, if you fancy it. Expect me to follow my website motto. This post is a patchwork of thoughts coming from going through actions module, some of those can be damaging or tedious or both.
I had a look at actions, it looks good. Can be cleaned up, but it is better to see what needs to mature further. The api reminds me of one ofthe evaluation models for lambda calculus (don't ask which or what - no clue, I'm bad with those things, if ain't in me bookmarks it ain't in me head).
The primitive, that is php coded actions, are atomic, and defined in some (environment) context. Something like action( $context, $arguments). Conditionals can be defined, for D7, for example. If the conditionals are cond( $context, $pred, $then, $else ). Since we are passing the context explicitly, nothing stops us implementing action closures - not on atomic actions, but on the upper level by adding something like a procedure, or abstraction, or whatever you like to call it, which has very simple 'stack' semantics. abs($context, arguments ) body the arguments get added to context if this form is used. Effectively something like this might happen (the meaning of the following, not how you would write it):
abs($context, $a, $b, $c) {
an_action( context, abs( $context + $a + $b + $c, ... ), ... )
}
Which means that an_action get passed a context ( which is defined when? ), and the new abs( some new non-atomic action, which has an extended context/environment.
It is a bit awkward. Essentially context == environment is cs literature. The problem is that it can become very messy. Especially that the current implementation allows something very close to dynamic scoping, which can be very awkward indeed. Very powerful, but awkward.
For D7 - (or D6, if you can do it), I would suggest using only context + action arguments, and for node actions, for example, stuffing the node object inside the context, essentially this would mean that the node is part of the action definition, or alternative phrasing(s) could be the node is in the action's scope, node action. Similarly comment, etc... The context can be (is already?) the omnipresent drupal 'structured' array. BTW, it's not accidental that this sounds like OO. It nearly is.
In the drupal array we can add #action and maybe #actions, so that drupal_builder calls those actions, stuffing the element into the context. This is the simplest way of doing it the 'new way', I think. Then we will end having two axis - time - load, alter, submit, .... and element - whatever that element is :) Hooks reinvented.
There are similarities with the callbacks as used in the structured array in form_api, and now more extensively in D6. I don't think there should be much difference between a callback and an action. Just actions can be manipulated by third party modules, like workflow, using an UI. Ultimately an action should be indistinguishable from a callback. There is still a way to go to reach it, but hey, there is time.
By the way, on a but different note. We are building a tree with annotations, the said structured drupal array, as used in drupal_alter. The order of execution of the callbacks per element, including drupal/form_alter is unknown. There is no protection about 'conflict of interest', that is one callback modifying the array in the same place where another wants to modify. Some form of sequencing might be nice. Since all callbacks are already encapsulated, some omitted by default because they are always executed, i.e. part of the workflow, implementing a 'monadic' treatment will be simple. Well, not really, since we don't have any convention, or an idea of how do we declare sequencing. The 'traditional' weights are a no go, since they carry little information and don't solve the problem, just delay it. I don't have the answers, just the questions.
