🚀 go-pugleaf

In article <42774@netnews.upenn.edu> rpotter@grip.cis.upenn.edu (Robert Potter) wrote:
>
> I don't know if this is the right group for discussing this, but I was
> wondering about a policy/style question:
> 
> 	Should the use of hook functions be abandoned in favor of the
> 	"advise" package?

Absolutely not!

> Seems to me that hook functions are ugly.  They can only be used if
> the author of the function you want to modify was smart enough to
> provide the hook (and to provide it in the right place).

When the author of a program adds and documents a hook variable, it is not
just an entrypoint to their code -- it is also a promise that an entrypoint
of that name will exist in the future.  Your code will continue to work as
planned with newer versions of the package, assuming the semantics of that
hook have not changed.

If you go and advise some random function in a package, you have no guarentee
that a future version will have a function of that name, that the function in
question will do the same thing, or that that function is even the appropriate
place to do what you want.  Basically, all bets are off.

Personally, I think that a general "advise" package is a bad thing, because it
encourages people to use it. :-)  Advising a function should take a bit of
work, because it's something that shouldn't be done lightly.

> Also, hook functions don't get access to the arguments/result of the hooked
> function.

If you want access to the arguments of a function, then you are probably
either making a substantial change to the way that function works, or doing
something which could be better done with more than one hook.

If a hook is "in the wrong place," then either the program has a bug, or what
you really want is a different hook than the one provided.

	-- Jamie