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

Judson Lester nyarly at gmail.com
Fri Feb 2 20:38:23 EST 2007


On 2/2/07, transfire at gmail.com <transfire at gmail.com> wrote:
>
>
> 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:

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

That's exactly it. Aspect::wrap aliases out the old method and
redefines it as an eval'd string, which interpolates the pre and post
advice for the method - even block calls are accomplished by
interpolating something like "block_find.call"

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

A quick spin with irb confirms that instances of X instantiated before
cut.rb was required are not modified, but even if X is defined before
cut.rb is required, then instances created after cut.rb is required
can be modified.

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

Oh, I completely recognize that it's more complicated than it looks.
My apologies if I've sounded at all underwhelmed of any of facets or
nitro/og - I'm incredibly impressed by both projects or I wouldn't
have stuck around so long.

For the most part, I think my objections are aesthetic.  The
order-of-require issue could be a problem elsewhere - if another
library has a similar requirement, for instance.  The other niggle is
that it modifies all classes, instead of just classes that need to be
cut.  That's why I raised the idea of modifying the cut class only.

>
> okay. FYI. Cut-based AOP, is founded on some theory. you can read
> about it here:
>
>   http://rcrchive.net/rcrs/1
>
Thanks very much.  I was trying to find a concise version of just the
theory to refresh from.  All I could find is a lot of AspectJ hype.

Judson


More information about the Nitro-general mailing list