From: Peter <Peter.Vanbroekhoven@...>
Date: 2003-12-02T02:58:51+09:00
Subject: Re: Underpinnings of Method Wrapping

> I was thinking about the terms. To really distinguish these two types of wraps
> for what they do I think the following terms, or similiar terms, would really
> nail them down and prevent any confusion, and also help us think about them
> better:
>
>   watch -or- monitor  =  extrinsic/outer wrap
>   submethod  =  intrinsic/inner wrap
>
> Does this work for you?

Watch is OK. Monitor sounds too much like the concurrency concept. I'm not
sure about submethod, since that sounds like the opposite of a wrap. Those
intrinsic wraps reminded me of the adapter pattern, although that does not
capture the full idea. But nonetheless, how about adapter for intrinsic?

> Also I was wondering, how do we get the results of super with the following
> code?
>
>  watch foo(*args)
> � � pre
> � � � a = something
> � � � # blah
> � � post
> � � � print a
> � � � # blah2
> � � end
> � end

Same way it happens in Matz's slides? Sorry, that's not nice. But I just
combined the pre and post from his slides, and never noticed that you
can't access the result there either, or at least it wasn't indicated how.
I think we can either replace post with post(res), or else use a global
variable. Or else reintroduce super.

> Note that I used watch instead of pdef just to see what it would look like. Of
> course this notation also has the sticking point of what happens if pre and
> post aren't given (error?) and also how does super wrapping fit into this?

I know, I was thinking that same thing. But it's a complicated matter.
Suppose we'd reintroduce pseudo_super, then what would a call to
pseudo_super do in another context? Oh, anda... If neither pre nor post
are given, that could perfectly be a syntax error provided we have a
separate keyword for a watcher (pdef, or wrap). And what do you mean by
"super wrapping"?

> Also, in thinking about the purpose of a "watch wrap" it occurs to me that it
> could still potentially effect the object (eg. @a = x) which I'm thinking
> should probably be beyond its "write scope". So perhaps it should be enclosed
> in some sort of object-specifc read-only namespace? Kind of like Matz'
> proposal:
>
>   http://www.rubyist.net/~matz/slides/rc2003/mgp00029.html
>
> But applicable to methods. In other words a "watch" should have access to the
> global namespace, but only read access to the local object's namespace. So  a
> "watch wrap" is equivalent to a "submethod" using this kind of namespace
> restriction:
>
> (using my repeated definition syntax from the RCR)
>
> def foo(*args)
>   namespace self
> �   a = something
> � � # blah
> � � r = escape { super }
> � � print a
> � � # blah2
>   end
> end
>
> Where 'namespace self' means that any effects on the object self, made within
> the namespace are "rolled back" at the end. But 'escape' means the namespace
> doesn't apply to what happens in its block.
>
> This is a bit confusing, I know. Really just thinking out-loud here. I hope
> the concepts I'm trying to convey make sense though.

I think I understand the concept. This "trick" won't prevent everything,
e.g.,

  self.name.gsub!(/^.*$/, "gotcha!")

Unless 'namespace self' extends beyond self to all self refers to directly
or indirectly. Isn't it needed also for args and r?

But now I'm wondering. Ruby assumes the programmer is the smarter one,
right? So why don't we just give the programmer the ability to decide what
happens with his wraps on redefinition and have him in good faith do the
correct thing? I'm OK with making it a bit harder to do the wrong thing,
but introducing overhead to make him do the right thing is stretching it.
So I'm definitely for making sure he doesn't meddle with the arguments to
super or the result of super, since that can be done syntax-wise. But
creating a complete sandbox for the watcher is too much.

So it's up to the programmer to declare his wrap intrinsic or extrinsic,
and have it respectively removed or kept in case of primary method
redefinition, and if it goes wrong, it's his fault. That's how Ruby works:
don't argue with the programmer, just let him hang himself.

Peter