Christoph R.
11/23/2003 3:03:00 PM
> -----Original Message-----
Ryan Pavlik wrote:
...
>
> Hmm, actually, there are a lot of good reasons for allowing
> multiple hooks in the same class. This is, AFAIK, the point
> of having hooks at all... so many people can hook into them.
>
> For instance, you may add a method:pre hook to check some
> parameter values, make sure they're in range. You may
> include a package which adds a :pre hook to add permissions. Etc.
>
> If you can only have one hook, what's the difference between doing
> this:
>
> class Foo
> def bar:pre
> # pre stuff
> end
>
> def bar
> # body stuff
> end
> end
>
>
> and doing this:
>
> class Foo
> def bar
> # pre stuff
> # body stuff
> end
> end
>
> or even this:
>
> class Foo
> def bar_pre
> # pre stuff
> end
>
> def bar
> bar_pre
> # body stuff
> end
> end
>
> To answer the question of order, it can either be
> configurable (I think CLOS allows this) or simply "stack
> order" (latest defined :pre goes first, latest defined :post
> goes last, etc.).
Not to allow several hooks still leaves open adding hooks
defined in ancestors Classes (that includes Proxy Module
Inclusion classes). The latter possibility pretty much mimic
CLOS "stack order" - see Guy's suggestion of including
wrapper-method Modules.
Personally I think this scheme is simpler and much easier to
implement compared to allowing multiple hooks that need
to be managed in some ways (each method needs to carry
around a manageable list of it's hook-methods). I can see
that this might come in handy occasionally but it does not
add enough (for me) to justify the added complexities of this
scheme.
On the other hand I am not that strongly opinionated about this ...
the addition of hooks in any form is certainly a great addition.
/Christoph