id	summary	reporter	owner	description	type	status	priority	milestone	component	resolution	keywords	cc	parents
638	meta-decorator hooks / emacs-lisp style advice	Christopher Allan Webber		"This is an incredibly evil and flexible idea that, like decorators itself, is probably elegant, hard to understand, powerful, and yes, a little bit evil.

So this is an idea inspired from emacs lisp, which allows you to pass in functions to wrap a function that already exists (this is called ""advising functions"").  Actually, hooks in emacs look a heck of a lot like decorators, so actually...

Say you have this function:

{{{
  @meta_decorator_hook('some_function_hook')
  def some_function(foo):
     bla bla
}}}

Now, you want to wrap this function!  But how do you wrap it?  It's already defined, you can't just wrap arbitrary things around it! ... or can you?

In this meta_decorator_hook, the meta_decorator_hook returns a lazy-loaded method set to actually construct a chain of wrapped methods.  So if we did something like:

{{{
  pluginapi.wrap_function('some_function_hook', our_function)
}}}

.. it would return, basically a WrappedFunction() that, the first time it is executed, walks through all the decorator like methods that have been pushed onto that hook and wraps them in each other. That meta-decorated method is cached, and eventually, executed.

Sounds evil, right?  :)

This could be super powerful though.  You could do crazy things like double-check the results of a view before returning it, or totally override the view and decide not to call it at all for your plugin, call it both before and after, or set up special-case exception handling for hooks that are called within the function itself.

I'm sure I didn't make that sound any less evil, but I think it'd be really great."	enhancement	accepted	minor		programming		pluginapi