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

On Wednesday 10 December 2003 05:55 pm, Peter wrote:
> > Mine too! But I was joking :) Well, half way. It would be nice to have a
> > good way, I was just throwing an psuedo example out there.
>
> OK, but even if you'd write end*5 or so, or end(5), then to see whether it
> is correct you'd need to count, while otherwise - if well indented - you
> can do it at a glance.

Well, I thought of using the underscores to allow one to indent as needed to 
line up the first and the last end with the rest of the code. But now I see 
that it is really a problem since the interpretor would have to depend on 
that indentation (or number of underscores) to make sense of it, which is 
yuk. But I did notice that if I switch to four spaces for indention (rather 
than the two spaces I normally use) this, in fact, works:

  class X
      def whatever
          if something
              # ...
  end end end

Too bad I don't like four space indentions ;)

> OK, that's what I wanted to know. I probably prefer to have a separate
> mechanism as foundation, although I can see how your singleton approach
> can work too.

What I don't like about a seperate mechinism is A) it will be essentially the 
same kind of mechinism, so you have two separate components of ruby doing 
essentially the same things. B) You now have to mange these two compenents 
separately and take into account all the considerations in which they may 
interact and/or conflict. C) Under the hood it looks pretty much the same: 
adding a wrap is adding an anonymous subclass of some sort and linking it 
into the class. And D) a seperate mechinism means much more code refactoring 
of the interpretor, more code, more overhead, and consequently more potential 
for bugs.

One might argure that there's something wrong with singletons being able to 
have there own singletons (i.e. meta-singletons), but I don;t see what that 
would be since, as long as one can still undef/redef the singleton layers as 
a whole (which one can), then meta-singletons are a complete logical superset 
on regular singletons.

> > Hmm, I think I may understand what your refering to now. I don't think of
> > it that way. For me all varaibles are of the same scope as they are now
> > --aspects don't have some special cross-cutting scope. For that you'd use
> > a class/module variable as we do now. Certainly one could invision such a
> > cross-cutting scope, but such a scope is not neccessary; and whether it
> > should be able to interact with the regular scope is again the difference
> > between passive and active wraps...
>
> I disagree. As I see it, there are two reasons for access control. One is
> encapsulation, to prevent other code to meddle with your data. The other
> is name clashes. The first is maybe a matter of self-control: you can
> meddle, but you shouldn't. The second is different, especially since we
> are talking about aspects that are rather snuck in without anyone knowing,
> but it might interfere still due to name clashes.

So you're thinking of advices not being in the same scope as the methods they 
wrap? But rather tha same advice shares a common scope across the 
cross-cutting concerns? So then you're talking about a whole different set of 
constructs to do AOP, since just using Ruby's current dynamicism could not 
facilitate this. Lets look at a psuedo example:

  aspect HereAdivces
    advice(tag == :here) do
      super
      puts @x, self.x
    end
  end

  class A
    apply HereAdivces
    attr_reader :x
    def a:here
      @x = "X"
    end
  end

  a = A.new
  a.a

What would this produce? If the advice had its completely own namespace:

   nil
   nil

The only thing you are left to "monitor" then is the return value of super. If 
on the other hand you suggest a partial namespace giving:

   nil
   X

Then this is really no different than having instance variables local to their 
class, which is, in some way or another, already on Ruby's drawing board. So 
the only difference would be forcing non-local instance variables to be local 
in advices, or making them illegal altogether (that is of course if we even 
end up any non-local instance variables).

Unless, I'm misunderstanding you (and seeing that this a complex subject we 
know that is quite possible :) I'm not seeing how this would work.

> > Active wraps need not alter functionality. Certainly they can, and even
> > here they have their advantages: easily removed and so serve as testing
> > code variations, they can be reused like mixins in appropriate contexts,
> > etc. But more significantly they can also be used to interact in a way
> > consistant with a class, injecting and extracting information without
> > "augmenting" behavior. I think this is the option you are not witnessing.
>
> Well, I think we seem to have a bunch of misunderstandings because of
> different interpretations of certain terms. To me what you just said
> rather proves what I said, and that's usually a bad sign... I think we're
> on the same frequency, we're only talking a different dialect. In the RCR,
> things like inner/outer wrap, passive/active wrap and such should be
> defined well, right? In case you'd be working on that, give me sign when
> that part's finished and then I'll take a look at it.

Good idea, I'll put those terms in the RCR tonight, and work on ading 
indicators, since I think we both agree on the utility of those. Yes?

I think the main differences in our appraoches, please correct me if I'm 
wrong, is that you're coming at it with a more formal understanding derived 
from AspectJ, while I'm coming at it more from having implemented wraps by 
hacking at Ruby. This is good, b/c it means we are attacking it from both 
ends.

> > Your response has got me digging up my old GUI code. Its been a while,
> > and I'd be hard pressed to tell you how everything works off the top of
> > my head, but I thought you might like to look at some of its heart. What
> > better example than a real one. If only I had a real AOP way to do,
> > rather then the mind boggling terseness of what follows. Have fun ;)
>
> Mind-boggling is definitely the right word. But I'm not exactly an adept
> code reader... But I'll figure it out sooner or later.

:) It actually looks harder than it is. What makes it so ugly is having to use 
___method___ to (hopefully) circumvent name clashes. If I remember correctly 
it essentially wraps every method of a class to which #when has been applied, 
or in the case of #bind, every single method of a class in order to hook on 
instance variable changes. I can give you an end result example of a GUI wrap 
if you'd like.

> I'll get working on those examples from the AspectJ website. It's a matter
> of translating them to Ruby, and to adapt some things to the fact that
> Ruby is dynamic. I'll use your syntax, and indicators where necessary.
> That's still OK, right?

Great! And the syntax is fine, easy enough to go back and make syntactical 
modifications when need be.

T.