From: Peter <Peter.Vanbroekhoven@...>
Date: 2003-11-28T01:44:07+09:00
Subject: Re: Method wrapping

> 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

What are wrappers going to be used for? Are you only supposed to add
wrappers to your own code? How about keeping some statistics about calls
to some library? I could write a proxy object that does that for me, but
wrappers are more flexible I guess. If I do that, some methods may have my
wrappers wrapped around them, or some of the library's, or some other
library's. That sounds plausible, doesn't it? Then if the wrappers are
removed on redefinition of a method, arranging the wrappers to be
reinstalled is a tough job, and it might not even be necessary if your
wrappers are defined well and the method changes are not at random.
Increasing arity can be caught with a *args in the argument list. I use
that in my initialize methods to call the initialize method in the
superclass. As such, I can add arguments to the initialize method of the
superclass and subclasses can beautifully pass them on without caring how
many there really are.

So my point is then that rarely wrappers would need to be reinstalled if
care is taken. If they do need reinstalling, the code for that isn't
always obvious and I don't need my code to be littered with weird,
unnecessary code.

> 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?

Like I said, wrappers can get mixed and I don't want to count on a certain
wrapper being in a certain position in the stack. If wrappers can be
added/removed, e.g., for turning logging on/off, positions change. Keeping
track of those positions is not my idea of good separation of concerns. I
like (optional) identifiers for wrappers better, but that's apparently
just me...

But again, what will be the use of those wrappers? A lot of it will depend
on that. If it's supposed to be used for modeling cross-cutting concerns
like in AOP, reinstalling wrappers could prove to be awkward.

Maybe I'm just thinking too much about all this...

Peter