Daniel Schierbeck wrote:
> I can't see why there *shouldn't* be multi-inheritance for cuts, unless
> you need to be able to find the exact class that's being cut by a
> certain cut.
>
>    cut Kut < A, B, C
>      def initialize(*args, &block)
>        puts "ahoy, mateys! arrr!"
>        super
>      end
>    end

That's a conceivable notation, but it's NOT multi-inheritance --we're
not creating a single class out of three. That's not what a cut does. A
cut is quite literally a *transparent subclass* so it simply augments
an existing class in a transparent way while maintaining a reasonable
amount of separation. Your example is really just a shortcut for doing
this three separate times, once for each class listed. The problem with
the syntax is that it is not Ruby-esque and we don't want to give the
false perception of multi-inhertiance which isn't there. Make sense?

So the way to do it is use a module and share that module. #preclude
works very well in this regard as long as don't plan on doing any fancy
dynamic inclusion to the module later on.

  module Kut
    def initialize(*args, &block)
      puts "ahoy, mateys! arrr!"
      super
    end
  end

  A.preclude Kut
  B.preclude Kut
  C.preclude Kut

The other thing you can do, if you don't require a single handle to the
concern, is write an easy-peasy crosscut method (maybe not a bad thing
to have in general):

  def crosscut( *classes, &blk )
    classes.collect { |c| Cut.new(c,&blk) }
  end

  mycuts = crosscut( A,B,C ) do
    def initialize(*args, &block)
      puts "ahoy, mateys! arrr!"
      super
    end
  end

No doubt one could go further and build a CrossCut class that holds the
code and a list of classes being cut. But that's framework stuff. As
I've said, the Cut is proposed to provide the strong foundation for
building all sorts of stuff like this.

T.