Hi, I should completely clear up one point: I do not want to change the systems I just propose to *unify* and *clarify* them (unfortunately that means change the current code)! A1. in the beginning I (wrongly) assumed that nodeapi() was the new API that unified in a single place the work with both node (full node type) and fields (fields added as a way to extend node functionality) A2. You guys helped by showing me the differences. So I assumed that I should use hook#operator() when working with nodes and _nodeapi(op=operator) when working with fields A3. The first problem of this orthogonal system, is that with the evolution it got we can easily forget to update both systems with the required hooks, examples: "delete revision", "search result" and "rss item"; forcing developers to make patches or use both hooks. A4. A nice and *orthogonal* system implies more code to maintain than a nice and *straight* system. A5. The second problem, is that is too easy to mix how this orthogonal system works. In fact some of you say that we should go with CCK fields to create new nodes, and in this case what is reason to have a system to work with nodes instead of only fields?! A6. This complex problem is result of insufficient documentation, a node system that has it's fully potential locked to the fear of changes, insufficient programmatic use of the node system by contrib developers. What I propose is the following (after reading all the messages here): P1. implement *all* hooks as hook_node#operator() -- eg. hook_node_load() -- which solves the naming scheme. P2. remove of _nodeapi(op=operator) which simplifies the system P3. add to the hook_node#operator() a parameter "when", allowing *all* modules to intercept "before" and/or "after" the event itself. Today with nodeapi(), we can only intercept "after". P4. Have the same functions to work the same logical way, helps doing a better documentation that is easier to understand. The hook_node#operator() would work with both complete nodes and extension fields. Think a bit... what can we do with the certain that we can intercept hooks "before", "on" and "after"?! Conclusion: I do not want to only do a simple name change. I'm proposing the leverage of the node system, so it can be more useful to implement much more flexible modules and easier to maintain. Regards, Fernando Silva On 1/5/07, Karoly Negyesi <karoly@negyesi.net> wrote:
* why do have we to use both?
Because http://drupal.org/node/50627 got little love. We are not perfect. Working on it though.
* if one will stand up, what will be?
Both will stand up.
Now, as I can see what you want is remove "nodeapi" stuff and convert it for the hook_node_foo naming scheme. Nice, I'll help you with that: * hook_load -> hook_node_load($when) * hook_insert -> hook_node_insert($when) * hook_nodeapi(op) -> hook_node_op($when) * etc, etc, etc
Still no.
If teddy.module implements a node type then teddy_load remains. Just I am trying to find a better name to call this, because the hook part of hook_load does not really fit. As said, functor came to my mind -- functor_load. Might be a bad idea. Do not know yet. It took me five years to get a good translation in Hungarian for the word 'bully'... Reason for this change: hook is something that is called by module_invoke_all or similar. Code change: zero. This is a documentation change.
But, if event module wants to add events to teddy nodes then it currently acts on hook_nodeapi op load. It's a true hook. Currently I think we would be better off calling this hook_node_load. Reason for this change: easier to fit into hook registry/order system. But then again -- hook_nodeapi#load could also be ordered. Just feel clumsy. Code change: for more complex modules, extremely little -- they have their handlers for different ops in different functions already.
If you want to further this discussion then give me reasons why your change is better than the current, nice, orthogonal system. I am not changing the system at all, just renaming stuff a little bit.