From: Peter <Peter.Vanbroekhoven@...>
Date: 2003-12-01T05:39:28+09:00
Subject: Re: Underpinnings of Method Wrapping

> > I like the proper separation, but why pre and post for extrinsic and def
> > wrap for intrinsic?
>
> Hmm, not sure how you're asking. Why different keywords? Or why different use?
> I'll just spell out in detail: I think that pre and post are different enough
> from def to warrant there own distinct keywords becuase pre and post can't
> change the method parameters or alter the return value, which def can.

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

> There are more important issues to ensure make it into future Ruby AOP,
> such as super wrapping and indicator tags and all the other stuff we've
> been talking about.

Rite. Let's drop that other subject then. Bang, boink, clang - it's
dropped!

> Considering you could hit every thing up using Object, plus common Mixins like
> Enumberable. That goes a long way. No doubt to be selective, well, you have
> to be selective one way or another. Right? So I'm not sure how you can do
> otherwise anyway. You have a specific notion in mind?

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

> Just to be clear, the indicators are just "tags", one still calls the method
> using just #eat, for instance.

Yes, of course. But if tags are used as an indicator to add certain
advice, we might want to indicate that multiple different "advices" apply
to the same method, hence multiple tags.

> So if your asking can we do:
>
>   def eat:eating:consuming
>     ..
>   end
>
> I'd don't see why not (an array of indicators?) But keep in mind you can
> always do pattern matching on the symbol:
>
>   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 :-)

> Yes, that *is* the optimization. You can see it clearly in the sourse code. It
> checks to see if the object is already pointing to a singleton or not, if it
> is it reuses the same class. I changed it to check to see if the method is
> already in the singleton class, if so it makes a "singleton for the
> singleton" (further subclass). So we still have the optimiztion, just not
> when the method's previously defined.

I understand. I just tried to say that the original implementation seemed
natural to me.

  class A
    def foo
      print "foo"
    end
  end

  c = A.new

  def c.foo
    print "("
    super
    print ")"
  end

  def c.foo
    print "["
    super
    print "]"
  end

  c.foo # [foo]

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

Peter