[Nitro] [OG] Aspects, cuts [was: eval and style]

transfire at gmail.com transfire at gmail.com
Fri Feb 2 18:07:11 EST 2007

On Feb 2, 4:43 pm, "Judson Lester" <nya... at gmail.com> wrote:
> On 2/2/07, transf... at gmail.com <transf... at gmail.com> wrote:
> > On Feb 2, 2:48 am, "Judson Lester" <nya... at gmail.com> wrote:
> > > Having spent a couple of hours looking at both, it seems very doable.  However:
> > > The biggest thing that Aspects does that would be tricky to replicate
> > > with cuts is incorporating strings as advice and the methods of advice
> > > modules.  I can see how that could be done, but especially regarding
> > > using Strings, I'm a little dubious.  Is that a feature of Aspects
> > > that's actually used?
> > case in point where i have no idea how this works. how are strings
> > advice?
> Because of the way wrap works, "strings are the simplest possible case
> of advice."

by "strings are the simplest possible case of advice."  do you mean
adding aspects to the String class? I'm not understanding something
basic about this.

> They're interpolated directly into the new method.

hmm... or do you mean that the pre and post code is defined as a
string, eg "x + y" rather than a block { x + y }

> It seems like the wrapped methods really ought to do something like
> call_advice_post
> __unwrapped_method
> call_advice_post
> Or something.  I'm not sure if advice should change after the fact or
> not.  A cut based replacement might be a better option, though.
> > > Regarding cut.rb, I'm a little leery of how fragile it seems to be.
> > > The comments suggest that it should be that absolute first file
> > > required, which is sort of a smell right there.
> > understandable and I am alittelmyself too. .... if an object is
> > instantiated before cut.rb is required, then you will not be able to
> > cut it --usually that is not a problem, but it's important to know.
> I'm still examining the problem, but it seems as if it should be
> possible for cut.rb to alter classes as needed, regardless of when
> it's required, since the key changes are made to the class, and all
> but singleton methods come from the class as-it-is not
> when-intantiated.

Yes, but if a class is instantiated (ie. X.new) then the resulting
object can't be cut unless cut.rb has already been loaded. hmm... in
fact it may not effect any object whose class wan't already cut when
it was instantiated. I don't recall for sure though.

> Fiddling with cut.rb, I can see that the magic comes by creating a
> proxy class.  Initial thought: what if instead a shadow class were
> created to hold the original methods, and calls were somehow delegated
> there.  There are obvious scoping issues with this, but it would allow
> pre-existing classes to be cut.

the proxy class is a subclass of the original so it's essentially
shadowed already. the problem is harder than you might expect. (btw
i've been getting this implemenation a little mixed up with my last
one that used a object extending module as the proxy rather than a
subclass --so a couple of my previous comments are off a little.
sorry) in anycase, i think the pre-existing classes issue isn't too
serious, i'm not sure what could prevent one form requiring 'cut.rb'
early on, as this issue only effects objects already instantiated
prior to loading cut.rb. but perhaps there's something i'm missing.

> > >  It looks like a lot
> > > of the stuff that wants to go into Class and Module might instead be
> > > able to be included into classes that get cut.
> > can you elaborate?
> Essentially, a Class that's been cut would have a new definition of
> "include" and "extend" that function as the reverse of
> Module#included, and have the method current in Class mixed in.
> Again, this would rely on inverting the relationship of the proxycut
> class and the cut class, and resolving the issues that creates.
> Honestly, the more I look at this, the more it's a huge architectural
> change.  Let me go away and fiddle with it, and I'll get back to you.

okay. FYI. Cut-based AOP, is founded on some theory. you can read
about it here:


I would have directed you to the original on the rubygarden wiki, but
the site is down :-(

> > > Maybe some sort of hybrid library would be preferable?  The
> > > metaprogrammic nicety of cut with the features of aspects, or the
> > > like.
> > well, cuts is "low-level", so i don't see hybridization being
> > practical.
> I really wasn't clear there, I think.  It seems trivial to add Cut#pre
> and Cut#post, and so incorporate most of Aspect's features.

oh I see. yes, that's doable via an extension. and that's basically
what I meant by wondering if aspects.rb could be built on top of
cut.rb. i don't know enough about how pre and post work to say for
sure though.

> > P.S. I keep wanting to put cuts.rb rather then cut.rb ... maybe I
> > should change the name.
> Ah, but the crucial method is Kernel#cut.  I'd recommend keeping the name.

true. I'll keep it. thanks.


More information about the Nitro-general mailing list