Re: Underpinnings of Method Wrapping

[snip]
>  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.

Actually it doesn't take into account either that if a method already
exists, it can be in the superclass or in the subclass (that's what
confused me about the first 4 lines. There you mean that the method exists
in the superclass but not in the subclass, right?) Just trying to grow
some more fun branches ;-)

Maybe an attempt to fill in the blanks in the decision tree... A wrap that
doesn't call super seems invalid, though I have no idea how to enforce
that super is actually called (except maybe by having the super call set
some hidden variable and check that at the end of the wrap). I don't know
what Matz had in mind there, he faces the same problem the way he did
wrapping in his slides.

Of course in practice only some branches of the tree will be useful. And
reordering the tests might locally decrease the depth of the tree, etc
etc.

Something else that occurred to me just now...

  def foo
    print "("
    eval("repus".reverse)
    print ")"
  end

This clearly calls super. But in general, it's impossible to know if some
method calls super. What I just mean to say is that the tree above can
only be evaluated at run time, not statically. That's not only hell to
those reading the code, but the idea of prime method is no longer so
well-defined. But I wonder whether that needs to be. I'll have to think
that through later on.

I think it would be necessary to make the decision tree above more
consistent. It would be nice if what wrap did was independent of the other
tests, and same for def. I know you wanted to do both wrapping, defining
and redefining with only def, but I'm just trying a different path, seeh
ow that looks.

> 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

Perfectly OK (no so-so :-)

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

I hope so too.

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

I know, that idea hasn't left my head yet. But it's really a hard thing to
do in Ruby because interfaces are hardly fixed. Unless we'd use interface
checking as Sean proposed, but that needs lots of careful thought as well.

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

I'll get to it this weekend probably. I'll get back to you then. I'll
probably retire from ruby-talk until then.

Peter

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

We've got a lot on the table, but we still have got lots of sorting out to
do I think. Also I have the feeling we've almost run in a circle, but it
doesn't feel like a lost effort.