[Nitro] [OG] eval and style

transfire at gmail.com transfire at gmail.com
Fri Feb 2 08:13:06 EST 2007

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

btw aspects.rb needs two things real bad: better examples and

> 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. a true implementation of
cut-based aop would have to be implemented in ruby's c code. cut.rb is
about as close as I think one can get in pure ruby. but it's still a
relativley new lib that hasn't been thourghly tested. it's hard to say
how fragile it is in the long run. the reason that it has to be
required first is becuase it effects all objects. 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.

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

> 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. cuts works by intercepting the #new call, so that any
instantiation of a class will be extended by a proxycut that holds the
advice. on the other hand, aspects.rb works by alias-wrapping every
method of a class. ideally cuts should be quite robust and serve as a
good foundation to build any aop-like lib, such as aspects.rb, but as
i said it remains to be seen how robust cut.rb is and/or what
improvements it may yet need to do the job well. i think it would be
worth the effort to try. if it works it will ensure the robustness of
both cut.rb and aspects.rb, if not then at least we'll know if cut.rb
is even worth keeping around, and i'm sure aspects.rb will be improved
by the effort nonetheless.


P.S. I keep wanting to put cuts.rb rather then cut.rb ... maybe I
should change the name.

More information about the Nitro-general mailing list