What is good name for something that registers itself to a hook?

[dlmr]

I'm working adding a easier way to extend things in Roc extensions (packages/plugins). One step to achieve this is adding a hook functionality where code can be added to change the behaviour of the original logic. This works great but I have a small problem related to the naming of the functions that register themselves to a specific hook, what to call them?

So my question is anyone has a good name for something that connects to a hook? Currently I'm using subscriber but does not feel 100%.

[voldern]

What about callback, as in register a callback with a hook, or maybe that is too ambiguous?

[dlmr]

I have though about it but as you say it is a bit ambiguous and might be confused with other types of callbacks that are common in JavaScript (and Roc).

So I'm not sure that is the best option either, however it might be better than subscriber since while it can't be mixed up with anything "generic" it can be misleading in other ways.

[wadim]

Hmm... what you call subscriber I would call "hook" and what you call hook I would call hook point. :)

[wadim]

add_hook, install_hook — these round right to me

[voldern]

What some other frameworks call them:

http://framework.zend.com/manual/1.12/en/zend.controller.action.html#zend.controller.action.prepostdispatch http://api.rubyonrails.org/classes/ActiveRecord/Callbacks.html

[dlmr]

Thanks for the feedback!

After thinking a bit more about it what do you think about calling them actions (instead of subscribers)? That would leave us at having hooks in our "logic" (the point of integration) and then we can register actions that will be invoked an do something, perform an action, when a hook runs.

However this will be kinda the opposite to how actions are normally done. An action would be "pre-server-started" and then a hook would be something that listens to that action and does something. I guess this kinda matches what @wadim wrote, although I'm not sure about calling them hook point.

However I feel that it would be more clear the other way around as I wrote above but that might be because that is the way I have seen if from the beginning and I'm not seeing it as someone that is new to the code would see and understand it.

[bjarneo]

Fish!

[dlmr]

🐟

[bjarneo]

But seriously though. Observer? In my eCommerce days this was the system: You used a dispatcher to dispatch an event, and used an observer to get the event.

http://code.tutsplus.com/tutorials/custom-events-in-magento-with-the-observer-pattern--cms-22120

[dlmr]

@bjarneo While it does do observe an event I feel like it might not be the best match here.

In a GUI system you add an observer unsure if the event will ever happen, or when it will happen. I think it makes sense to say that it observes for changes but they might never come.

In Roc we instead have events that we know will trigger and we also knows exactly when they will happen. So while it technically observes it, at least for me, does not conveying the purpose and function of them in an optimal way. I feel action is more fitting then because it will happen and we know it for sure.

What do others think?

[bjarneo]

Well, I think action fits your description.

[dlmr]

I will go ahead and change from subscriber to action now.

Please continue this discussion if you feel that there is a better alternative or if this still might be confusing.