> What you need is sometimes called a "trampoline" - an object that
> simply "bounces" any messages it receives:

That's interesting. ... and very cool passing a block like that.

Unfortunately, I think it simply delays my problem. Let's see if moving from
example to actual clarifies.

I'm wrapping dom nodes. Form element dom nodes. I'm wrapping them so my
customer can script his own tests. Most of the time the script writer needs
to simply set the value of a form element, but a straight call requires
setting the .value property:

  form.anElement.value = blergh

I wrapped this so the script writer would not have to remember .value all
the time:

  form.anElement = blergh

What I do is intercept anElement and re-route the call to anElement.value.
Works great.

Then today, anElement is a checkbox, and now I don't need .value, but
.checked. So this:

  form.aCheckBox.checked = true

...gets munched by my wrapper into:

  form.aCheckBox.value.checked = true

and, of course, that doesn't work. If, in my wrapper, when I convert the
aCheckbox method to aCheckbox.value, if I could know that .checked was
coming next, I could skip the conversion. 

So it's a conditional trampoline, but the functionality of the Trampoline
block would be dependent on method calls not passed to it yet. 

...

Now that I've talked this out, for the moment at least, I can detect that
aCheckBox was a checkbox node and react according to that instead of trying
to predict the future. 

That, or I chunk this whole wrapper idea and make the script writer tack on
.value everywhere.

Chris