From: Peter Date: 2003-12-03T11:21:53+09:00 Subject: 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.