From: Peter <Peter.Vanbroekhoven@...>
Date: 2003-12-11T01:55:56+09:00
Subject: Re: Underpinnings of Method Wrapping

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

> But it dosen't need to be. These aren't just "wrapping-like things". It *is*
> wrapping. And with only some basic modifications, i.e. meta-singletons and
> class defineable singletons, can be the very foundation of AOP for Ruby.

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.

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

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

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

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?

Peter