T. Onoma
11/27/2003 3:21:00 PM
On Thursday 27 November 2003 02:55 pm, Peter wrote:
> Removing hooks on change of a method means all hooks have to be added
> again needlessly in some cases. And if a change is incompatible with the
> hooks, you can remove or redefine them yourself once there's an API to do
> so. And my guess is it will be less work to remove hooks manually than to
> add hooks manually because if you're careful most hooks remain valid. And
> besides, on large changes to signatures of methods, you'll have a lot of
> work to adapt the rest of the code anyhow.
I can understand where you're coming from with this. You want the
functionality there just in case for those "some cases". But by and large you
won't want this behiavor (for many reasons), so it really should not be the
default. On the rare occassions one does want it, then there can be means
available to replace the method chain's "heart" or even any particluar wrap
layer. But doing so should have its own special method, not the other way
around. Otherwise we're going to end up with *a lot* of code heavily littered
with:
remove_method(:ameth)
def ameth
end
That's certainly not the Ruby Way. I'm not sure what kind of method to use for
your case though, perhaps like
selective_def(index, :ameth, *args) do
end
To replace the "heart" you'd use index=0. Hey! Better yet, perhaps we can have
some array like sugar:
def ameth[0](*args)
end
I think that would work nicely. You?
-t0