Chris,
Sorry if my density is getting the way of understanding here. :-)
It's probably not density on your part, but just the way I think about the pattern.
function, and your module somehow registered that such a function is available, how is it not a callback?
Unlike C, I'm not explicitly registering nodetype_operation() to be called in the hook_load() pattern. If the function exists, it is called when appropriate, if it does not exist, it is not called. In my way of thinking, if I don't explicitly register it and some bit of code is hot maintaining a function pointer to my callback, it's not a callback. I'm not being called 'back', rather core is calling out to a function that I can declare if I want to. It is a subtle difference, and not one that I'll go to the mat defending as The Right And Proper Way.
core just looks for the function, then it sounds like a hook -- which given other messages it seems like it is not.
The differentiation that chx is making with hooks vs 'something else' is that something like hook_nodeapi() is called on every implementing module every time the hook invocation function is called. It is up to each hook_nodeapi() implementation to figure out when to act and when to remain dormant, and in general any given hook_nodeapi() implementation should not rely on the order in which the hooks are called. hook_form_alter() follows this same pattern, as do many others. hook_load()/hook_insert() and such are called explicitly as a single function call based on the node type. In this pattern core is not calling a series of functions across all implementing modules, but rather calling a single function if it happens to exist. Larry Garfield thought he was being evil by suggesting 'method_load()' as the pattern name. That's not a bad idea either. I've chimed in on this thread because the distinction between hooks that are called in an 'unordered' (ignoring system weights) set vs the hooks that are called based on node type was not clear to me when I started with Drupal two years ago. Both were called hooks, and it took me a while to work out that they were different. I was confused as to when I needed to check input parameters to decide whether to take an action, vs when my function was expected to take an action no matter what. From the module authoring perspective that's a big difference. Like many others, I just cut and pasted from working code without really getting it (for a while). I'll happily field follow-on questions to my warped world views, but in the bigger picture I think this thread has probably run it's course. Scott Chris Johnson wrote:
Scott,
Can you clarify a bit between why "callout" is ok but "callback" is wrong. I understand your remark about not passing a function pointer into something to get called back (I'm an old C kernel device driver programmer). But if something in core is calling out to your function, and your module somehow registered that such a function is available, how is it not a callback?
If I'm confused here, and you didn't register the function (you passed an object, so that seems like a positive registration action), but core just looks for the function, then it sounds like a hook -- which given other messages it seems like it is not.
Sorry if my density is getting the way of understanding here. :-)
Thanks.
..chrisxj