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

Judson Lester nyarly at gmail.com
Fri Feb 2 16:43:08 EST 2007


On 2/2/07, transfire at gmail.com <transfire 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.  They're interpolated directly into the new method.  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.

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.

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

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

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


More information about the Nitro-general mailing list