T. Onoma
12/2/2003 2:17:00 AM
On Monday 01 December 2003 06:58 pm, Peter wrote:
> > 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?
OK as in so-so, or OK as in yes? If just so-so we'll find something better. I
thought of using 'sub' to convey the use of super within the method, and its
kinship to subclassing. But I see what you're saying b/c it's sort of like
subroutine. In fact submethod would be synonymous with wrap. But I'm not too
keen on adapter either because the method's interface doesn't have to change.
Also, in that case we'd probably call a watch, an observer. I don't know if
we want to refer to them in terms of similiar design patterns. Here's some
alternatives I came up with for inner wraps: touch, affect, yoke. By the way
I searched google a bit, but I couldn't find anything in the way of these
terms (except for a number of ruby-talk posts ;-).
> > 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.
:-)) matz posted earlier that he had not good "structure" for doing so.
> > 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"?
This is thorny and I'm starting to think there's no way around using super.
super just can't take variant args in an outer wrap.
A super wrap is the join points up against super in the method being wrapped.
I like to call it a shrink wrap :-)
def x
print "X"
end
def x
print "<"
super
print ">"
end
def x
superwrap
print "("
super
print ")"
end
end
x; puts # => <(X)>
I discoverd the need for this when working on my gui interface. It alows you
to keep the super in the method being wrapped wherever it needs to be
relative to the advices.
> > 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:
[snip]
>
> 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.
You're right. We can't save the world with one outer wrap. We need not be
concerned with such "over" protection, just so long as we protect the method
interface.
BTW: did you read ruby-talk:86785?
-t0