Re: [Monotone-devel] Hooks...

[Stephen Leake]

Richard Levitte <address@hidden> writes:

> In message <address@hidden> on Wed, 5 Sep 2007 09:34:01 -0300, "Alex Queiroz" 
> <address@hidden> said:
>
> asandroq> 
> asandroq>      Yeah, it's a good proposal. Give events names and then:
> asandroq> 
> asandroq> add_hook(event, func)       -- adds a hook and returns an id
> asandroq> remove_hook(event, id)     -- remove previously added hook
>
> We need to think a few steps further, me thinks:
>
> - What do we do with the values returned by the hook functions,
>   especially if one event has more than one hook function registered?

In this case, `add_hook' returns an id, which is only useful for
remove_hook. So I think that's clear.

I don't see that remove_hook should return anything.

> - Do we want to make it possible to give a priority to hook
> functions? That would require a priority parameter to add_hook(). 

I think add before or after the current hooks is sufficient; Emacs
gets by with that. 

If you need something more complex, you can write code to remove all
the current hooks and add them back in some order.

Hmm; that means remove_hook should treat a null id parameter as 
meaning "first hook", and return the id of the hook actually removed.

> - Do we want a third function that returns information about a hook,
> such as how many functions are attached and their identities (the id
> returned by add_hook()), and whatever other data there may be. 

That might be useful for the "remove all and add back" scenario.

> - Do we want to be able to identify some hook functions by name?

I'm not clear what this means. Ah; not all Lua functions have names;
they can be dynamically created. So are you asking whether functions
passed to `add_hook' _must_ have names? I don't think that should
matter (and can Lua tell whether a function has a name? I guess it
probably can).

The hooks themselves must have names. Current the "name of the hook"
is just the "name of a Lua function that is called at some specific
point"; this mechanism would replace that with some more formal name,
and the function the hook actually calls could have any name, or none.

However, there are probably existing hooks that should _not_ execute
more than one function. "ignore_file" comes to mind; what would it
mean to have two ignore_file functions? The current one returns a
boolean; how would more than one result be combined? One reasonable
way would be for the hook execution stop when one function returns
True. But is that what we want for all hooks?

-- 
-- Stephe