Re: Method wrapping

On Thursday 27 November 2003 05:44 pm, Peter wrote:

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

Maybe your misunderstanding me (or vice-versa)? B/C I basically agree with 
what you're sayng. But you don't have to reinstall the wrappers. You will 
just add another wrapper in your case, not replace the "heart" method. Do you 
know what I mean? Your saying if it is all "defined well and the method 
changes are not at random" then this should be all you need. If you really 
find yourself in a position where the "heart" method needs to be changed 
without effecting the wrappers (kind of like pulling out a table cloth but 
putting one back too) then there is good reason to think that your main 
method should actually be in its own superclass. In which case you could 
change it and your subclass methods will still be there.

In other words we don't need to overburden the wrapping mechinism with 
functionality we arleady have that more clearly seperates concerns. A method 
and its wraps within the same class should be seen as a whole, not separate 
methods. So *redefining* should effect them all.

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

I agree. I don't even care for being able to index them at all, but it seems 
some people feel we need some way to access them. Indexes don't require extra 
"naming" syntax. But you are right, they would be pain to mange, so only good 
for mucking around.

But the naming thing does spark some interesting notions. I will consider this 
in detail to figure out how it could/would work. Let you know what I come up 
with.

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

It's good to think about b/c it is a actually an additional paradigm for 
coding and we should get it right. Have you read my AOP RCR?

-t0