Re: Underpinnings of Method Wrapping

> True, true. And I really have no idea. I suppose it really depends on just how
> much of a speed hit occurs as to whether it will require special attention.

We will see. But it may not be so obvious to measure the decrease in speed
(if there is any).

> "Duh!" [tom's smacks his forehead] I thought you must have already been aware
> of this, and thus must have meant something more specific, but I did not see
> what it was, so i just assumed perhaps it "clicked" for you or something
> instead. Sorry, I see what you're getting at now.

That's the second person this week whom I have smacking his forehead...

> Think they call that an RCR these days :)

:-)

> And "duh!" again [tom's smacks his forehead again] I've actually been holding
> on to my notation tighter then I thought! Indeed I was thinking implict,
> actually I was thinking of both ways, implicit and explict. But in all my
> examples I defaulted to implicit and so never really considered the
> significance of their difference -- implict wraps aren't nearly as useful,
> especailly when defining wraps in a class definable way.
>
> So let me just say this is actually brilliant Peter.

Thanks, but the idea was really yours. I just happened to interpret it the
wrong way :-)

> No. Not to this extent, anyway. For explict I was thinking more along the
> lines of another keyword like "preclude" (I know, bad use of the word) akin
> to include.

I know. I almost used the keyword in my examples, but it's confusing.
Preclude (as a variation of include) makes me think of rather the opposite
of its intended purpose.

>   module MyAspect
>     ...
>   emd
>   class MyClass
>     preclude MyAspect
>   end
>
> Or having a module split into sections, one that does normal mixin including
> and one that does the singleton mixins, but this is weak.
>
> I think you've hit the ultimate notation! :)

Actually those Wrappers can also do normal mixing in. It's weird how such
a simple idea is so hard to think of. But most good ideas are really
stumbled upon, right? But we still need to evaluate it for catches.

> In fact, I was thinking about this today, and realized clearly that this is
> the other way in which wraps can implemented. I wonder if Matz is thinking
> along these lines rather then our subclassing line? It's not a far shot to
> imagine that his notation:
>
>   def meth:wrap
>     # pre code
>     super
>     # post code
>   end
>
> actually translates under the hood into something like:
>
>   alias_method 'meth:wrap'.intern :meth
>   def meth
>     # pre code
>     send('meth:wrap')
>     # post code
>   end
>
> which is certainly doable, and probably faster in execution, but nowhere near
> as clean and flexible as our approach. Something to think about though in
> comparision.

Actually I always thought that you meant wrapping to be this way, that's
why I was confused about the singleton stuff. But I wasn't happy with it
since this way of wrapping had the same syntax problem. Well, not quite,
we use it this way already for hooking into method_undefined and all, but
note that the above is only one layer again. If we add a second layer,
meth:wrap will clash as a name. So we need something more anonymous, and
then the syntax problems reappear again.

> I agree. That kind of wrapping really needs to be left to the interpretor
> itself to expose.

I don't understand what you mean by this. If you want to allow wrapping,
the interpreter has to provide a way to do so, and hence expose something.

> I've decided I must be totally missing something here, because I'm just not
> fully following. I see that you want instance variables private to an Aspect,
> unseen to the classes the aspect effects, but thats all I can really gather.
> For instance, "and other stuff to keep the links consistent", just dosen't
> mean anything to me. Sorry if I'm being dense, sometimes I can't see what's
> staring me right in the face. I'm going to go back and look at your
> bidirectional example. Maybe that will help it click for me.
>
> Anyway, don't think I'm against this idea or anything, I'm just not yet
> understanding it.

We all suffer from denseness, don't worry. I'll keep trying from time to
time with different examples/perspectives.

> umm... "super duper superb". Will that do?

If I were someone who blushes, I'd be blushing now. So yes, it certainly
will do :-)

> Further, I have some ideas to elaborate on this too, but I'm a too tired to go
> into iit right now. I'll put it in another post.

OK.

Peter