From: "T. Onoma" <transami@...>
Date: 2003-12-01T07:19:14+09:00
Subject: Re: Underpinnings of Method Wrapping

On Sunday 30 November 2003 09:39 pm, Peter wrote:
> Never mind, I think I've answered my own question in meanwhile. pre and
> post can't alter the result of the method calls, which makes them ideal
> for the "meta-tasks" (extrinsic). def can alter the semantics of a method
> which makes them ideal for the intrinsic part. But it might sometimes be
> convenient to use def even for something extrinsic because of something
> like this:
>
>   def foo(*args)
>     # set a here, do other stuff not affecting the super call
>     result = super
>     # use a here, do other stuff not affecting the result
>     result
>   end

You're absolutely right. Hmm...Granted this is acting in accordance to an 
intrinsic wrap, buit it's not gaurenteed. So this is fine, but if foo is 
later redefined this wrap will be flushed (at least IMHO it should be). But 
we need to solve the problem you present., so either pre and post must be 
considered essentially connected in scope with access to the same vars, which 
seems rather odd, or we can just have an intrinstic wrap defintion like:
 
  wrap foo(*args)
    # set a here, do other stuff not affecting the super call
    result = psudeo_super
    # use a here, do other stuff not affecting the result
  end

Then we don't need pre or post. I suppose if no "psuedo_super" is given it 
would be assumed to be like a pre? I'm not sure. What do you think?

> I think we misunderstood each other again, but correct me if I'm wrong. I
> think you thought I meant adding the same aspect to methods in different
> classes, right? I meant adding different advice to methods in different
> classes but share the same "private, yet global vars".

Your right. Sorry. But I do think sime of the same basic methods apply. Not 
sure. I guess I need some examples to really be able to consider.

> >   method(eat).to_s.tag =~ /consuming/
> >
> > So I don't know if we really need to do beyond a single indicator symbol.
>
> I'm short-sighted as usual, you're right :-)

Ha! You should see how thick *my* glasses are! :-)

> This to me is just the same as doing:
>
>   class A
>     def foo
>       print "foo"
>     end
>   end
>
>   class A_c < A
>     def foo
>       print "("
>       super
>       print ")"
>     end
>   end
>
>   class A_c
>     def foo
>       print "["
>       super
>       print "]"
>     end
>   end
>
>   c = A_c.new
>
>   c.foo # [foo]
>
> I admit, this makes the second foo look like a wrapping and the third like
> a redefinition. 

I hold my tounge ;-)

> But this is consistent with the idea that each object gets
> its own singleton class (though in the implementation it is only created
> when necessary), and defining object.foo is like adding the method to
> object's singleton class. The Pickaxe doesn't say it this way, but instead
> goes into detail of implementation. But that was my way of thinking about
> it on an abstract level that is consistent with the implementation, and
> there was no wrapper idea involved. That's what I tried to say. But if you
> really look at it as some wrapping mechanism, your new implementation
> makes more sense.

I think you're right on. My implementation, instead, just adds more of the 
same:

   class A
     def foo
       print "foo"
     end
   end

   class A_c < A
     def foo
       print "("
       super
       print ")"
     end
   end

   class A_cc < A_c
     def foo
       print "["
       super
       print "]"
     end
   end

   c = A_cc.new

   c.foo # [(foo)]

-t0