From: Christoph Date: 2003-11-24T00:02:33+09:00 Subject: Re: Method wrapper question (was "stereotyping (was ...)) > -----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