Re: Underpinnings of Method Wrapping

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

I'm in the so-so zone. I've been looking for suggestions myself, but my
mind is currently a blank. And tired.

> :-)) matz posted earlier that he had not good "structure" for doing so.

That proves that it's a toughie :-)

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

Yeah, but:

  class X
    def x(a)
      print a
    end
  end

  class Y < X
    def x(a)
      a += 1
      super
    end
  end

  Y.new.x(5) # => 6

We'd need yet another semantics for super in this case.

> A super wrap is the join points up against super in the method being wrapped.
> I like to call it a shrink wrap :-)

If you had called it that, I'd have known what you meant right away!

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

Everything seems to point towards super needing to be explicit, except our
wanting to protect the programmer from making mistakes... See below.

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

But to go a bit further, I'm wondering whether we should make a difference
at all and just have the programmer indicate whether the wrap should be
removed on primary redefinition or not - I mentioned the basic idea once
upon a time in [ruby-talk:86551]. Even wraps that are intrinsic can be
generic, e.g.,

  def foo(*args)
    args.map! { |a|
      if a.respond_to? :unpack
        a.unpack
      else
        a
      end
    }
    result = super
    if result.respond_to? :pack
      result.pack
    else
      result
    end
  end

I realize pack and unpack clash with the methods of String and Array, but
that's what those method indicators are for. But point is that the method
above not necessarily needs discarding, even if it does influence the
arguments and result. So maybe that too is up to the programmer to decide.
If he says the wrap should be kept, and it breaks things, then he should
fix it. If he was right, all's well.

I know that that's a break from Matz's proposal for pre and post where the
call to super is implicit and it is (apparently) easily enforced that the
arguments to super and its results are left alone. I never questioned that
that was a Good Thing. But it's only skin deep since the internal state of
the arguments and results can be changed anyhow (String#gsub! being an
example); also the internal state of self can be changed, and all
practical protection against that is again only skin deep. We can protect
the interface - or the skin if you want - but to what avail?

So my conclusion is that maybe we should have two separate keywords for
"submethod wraps" and "watch wraps", and be done with it. Ruby will
discard the former when the primary method is redefined, and will keep the
latter. And the rest is the programmer's responsibility. What do you
think?

Hmmmm, thinking about it some more, it seems that maybe we're unifying two
concepts that are really orthogonal. On one hand there's whether a wrap
should go when the primary method goes or whether it should stay. On the
other hand there's whether the interface (args + result) is meddled with
or not. I think the former is a functional difference, while the latter
feels like a documentation issue because nothing happens with it at run
time.

> BTW: did you read ruby-talk:86785?

I read it, but not thoroughly. It's on my toread pile for when my mind
unblanks.

Peter