Re: Underpinnings of Method Wrapping

Peter:

You won't beleive what I just did! I am working on a program for 
distrowatch.com and I decided I wanted to change how a method worked in a 
standard class, I speedily typed:

  class NilClass
    def split(*args)
      super || [ ]
    end
  end

Thinking split already existed. Of course then it dawned on me that NilClass 
doesn't have a split function yet, so the super would not work anyway despite 
the fact that I'm also not making a subclass. All of which is very telling, 
because as a programmer (or as the Ruby interpretor) the following descision 
tree must be figured out:

 subclassing -> exists -> def -> call super => outer class wrap
 subclassing -> exists -> def -> no super => redefine
 subclassing -> exists -> wrap -> call super => same as def or ERROR?
 subclassing -> exists -> wrap -> no super => same as redef or ERROR?
 subclassing -> not exists -> def -> call super => ERROR
 subclassing -> not exists -> def -> no super => define
 subclassing -> not exists -> wrap -> call super => ERROR
 subclassing -> not exists -> wrap -> no super => same as define or ERROR?
 not subclassing -> exists -> def -> call super => redefine w/ out. class wrap
 not subclassing -> exists -> def -> no super => redefine
 not subclassing -> exists -> wrap -> call super => wrap
 not subclassing -> exists -> wrap -> no super => same as redef or ERROR or?
 not subclassing -> not exists -> def -> call super => ERROR
 not subclassing -> not exists -> def -> no super => define
 not subclassing -> not exists -> wrap -> call super => ERROR
 not subclassing -> not exists -> wrap -> no super => same as define or ERROR?

Lots of fun, huh? ;-)  And this doesn't take into account the descisions of 
outer vs. inner wrapping.  (Note: class wrap means the effective wrapping of 
the superclass' method; it is necessarily outer) So if you ask me the above 
descision tree is too complex, and is really on the verge of becoming too 
unwieldy for any ordinary programmer.

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

I will keep calling it that then. :-) For clearity I'm going to start using 
the following terms:

  outer - a wrap that remians even when the prime method is redefined
  inner - a wrap the is removed when the prime method is redefined
  passive - a wrap that does not alter functionality in any way
  active - a wrap that alters functionality in some way
  shrink - same as superwrap

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

That's a good point. And I am leaning in its favor. But to be sure about this 
I think we will need to carefully think about how code gets reused. With 
patient thinking on this matter, we'll come to a certain conclusion on how 
this should work.

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

Well, it dosen't matter so much what Matz has previously thought, if we find 
something better for good reasons. And if we explain it well enough he'll 
understand (I hope).

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

I like the simplicty of it. But I'm not sure yet. Something tells me that 
having a safe way to wrap, even if its only method interface safe, is 
important.

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

Yep, pretty close to right on.

> > BTW: did you read ruby-talk:86785?
>
> I read it, but not thoroughly. It's on my toread pile for when my mind
> unblanks.

Get to it when you can. I think there's a good idea in there that's related, 
basically the idea of singleton mixins.

-t0

P.S. By the way, I think we've certainly come along way already!