From: Jeff Wood <jeff.darklight@...>
Date: 2005-10-19T23:34:07+09:00
Subject: Re: [RCR] Cut-based AOP

Although I see the power of the examples and the ideas, it seems like
it's a bit watered down compared to AspectJ or other Aspect
frameworks.

Usually, the definition of cuts allow you to wrap many things at once...

AspectJ ( for instance ) allows you to use wildcards in both the
object type and the  method names that are getting wrapped.  It allows
you to add general functionality ( like debugging logs or security
control ) very easily to chunks ( of any size, even all ) of your
application.

I'd like to see something like that for Ruby, but I do think that your
idea is a good start.

maybe something that allows cut to take some wildcards

Cut.new( "FileLogging" ) do

  wrap_method( File, :any ) do |method, *args|
    # do logging stuff
    method.call( *args )
    # do more logging stuff
  end

end

or instead of File ...simply

  wrap_method( IO, :any ) ...
    ...
  end

which would turn around and add this cut to any object of that type (
or a derivative ) of IO

Anyways, just additional thoughts.  Shouldn't be too hard to implement
as objects now within Ruby as it exists...

The only trick is catching overrides and new types that are defined
AFTER the cut has been added.

... just my $0.02US

j.


On 10/19/05, Peter Vanbroekhoven <calamitates@gmail.com> wrote:
> On Wed, 19 Oct 2005, Dave Burt wrote:
>
> > Peter Vanbroekhoven explained:
> >> On Wed, 19 Oct 2005 dave.burt@gmail.com wrote:
> >>
> >> Did you mean the following? (Otherwise the class definition of Bar is
> >> useless.)
> >>
> >>    Foo = Bar
> >
> > Quite. Let's imagine that's what I said.
>
> Done :-)
>
> > OK, great. I'm starting to see the usefulness of this. It occurs to me that
> > there is some similarity between this and selector namespaces (targeted for
> > Ruby 2) -- a lot of what I imagined namespaces being useful for (i.e. making
> > changes to a core class that only affects code within a particular limited
> > context) is accomplished easily using cuts.
>
> There are definitely parallels, but cuts are at this moment not
> context-aware by themselves. Something like namespaces can be done as
> follows:
>
>    cut FileLogging < File
>      def initialize(*args, &blk)
>        do_some_logging if Thread.current[:LOGGING_ENABLED]
>        super
>        do_some_more_logging if Thread.current[:LOGGING_ENABLED]
>      end
>    end
>
>    def with_logging
>      old_logging = Thread.current[:LOGGING_ENABLED]
>      Thread.current[:LOGGING_ENABLED] = true
>      yield
>      Thread.current[:LOGGING_ENABLED] = old_logging
>    end
>
>    f1 = File.new('some_file') # => no logging
>    with_logging do
>      f2 = File.new('some_other_file') # => with logging
>    end
>
> I think though that this is different from selector namespaces, as my
> example provides different behavior in a dynamic scope, and selector
> namespaces are about static scope. That's provided I understand about
> selector namespaces myself.
>
> > I still don't know anything, really, about Ruby namespaces. Something else
> > to look forward too, and something complementary to this, I guess.
> >
> > Last thing, a criticism: shouldn't cut be a module, but not a class, because
> > classes are instantiable?
>
> First things first: when you talk about cut, is that Cut, or an instance
> of Cut? If it's the latter, then the answer is that we had long
> discussions about whether Cut should be a subclass of Class or of Module.
> There are some features that make it class, and some features that make it
> a module:
>
> * a module because:
>    - Not instantiable (though singleton classes aren't instatiable either)
> * a class because
>    - Not includable (though neither is Class which is a subclass of Module
>      too)
>    - It has a superclass, namely the class it cuts
>
> So you see, there are arguments for both, and in the end we settled on it
> being a class.
>
> Peter
>
>


--
"http://ruby-lang.org -- do you ruby?"

Jeff Wood