Selon Peter Vanbroekhoven <calamitates / gmail.com>:

>
> Great! One down, many more to go ;-)
>

LOL! Seriously, I really hope this RCR gets accepted. It is nicely
non-intrusive, and brings functionality that I'm sure many people would use if
it was there.

> > - will one be able to subclass (are rather "subcut", one would say) cuts?
>
> Cuts are not supposed to be subclassed (they can't be instantiated, so
> what is the point?)

I agree, which is why I corrected myself and said "subcut" afterwards :) .

 We're not sure if we want to allow adding cuts to
> cuts. I think the current implementation allows that, but I'm not sure,
> it's been a while.
>
> If you want to reuse the functionality of a cut somewhere else, you should
> put it in a module and reuse it like that. In a way, allowing a cut to
> apply to multiple classes or modules is akin to multiple-inheritance, and
> we want to avoid that.
>

I find it a great idea to use modules for cuts to. A genial way to minimise the
amount of new features to implement and learn!

> > - will cuts be as open as classes? (since they *are* classes, I'd expect
> so, but
> > I just want confirmation)
>
> Yes, they will be open wide.
>

Good :) .

> > - how do cuts work with each other when you add more than one cut to the
> same
> > class?
>
> They stack on top of each other, the last one added being on top:
>
>    class A
>      def m ; '1' ; end
>    end
>
>    cut B < A
>      def m ; '[' + super + ']' ; end
>    end
>
>    cut C < A
>      def m ; '{' + super + '}' ; end
>    end
>
>    p A.new.m # => "{[1]}"
>

So they will be stacked on top of each other, in a manner not dissimilar to how
mixins work. Nice and simple :) .

> > - will the subclass of a class also inherit its superclass's cuts? This is
> a
> > tricky point I think, as one might expect that the functionality provided
> by
> > cuts should be available to subclasses, but the implementation (which is
> > basically like transparent subclasses) may forbid it. If they don't inherit
> > cuts, this could lead to surprises, with a not overriden method behaving
> > suddenly differently in the superclass and in the subclass. And what should
> one
> > expect of the behaviour of "super"?
>
> Yes, subclasses inherit the cuts. This means that in the class hierarchy,
> the cuts are in between the class and the superclass. To show this, some
> example code:
>
>    class A
>      def m ; '1' ; end
>    end
>
>    class B < A
>      def m ; '{' + super + '}' ; end
>    end
>
>    cut C < A
>      def m ; '[' + super + ']' ; end
>    end
>
>    p A.new.m # => "[1]"
>    p B.new.m # => "{[1]}"
>
> So the methods of a class are seen the same from the outside and from the
> subclasses.
>

So I don't have to worry that subclasses would suddenly behave differently from
their parents without explicit overriding. Cool.

That said, I'm suddenly thinking that sometimes one would rather want to
subclass the class as it stands without its aspects. If I'm thinking for
instance of the issue of logging. The way it stands now, if the parent class
gets a logger cut, the subclass suddenly gets logging functionality *in the
middle of its overridden methods*, when they use super, whereas one would
rather expect the logging aspect to be *external* to the implementation of the
subclass (if it is to be there at all). I hope I'm making myself clear. I have
difficulties to express my thoughts in words today...

What do you think? I like the way cuts act in a really transparent way, and that
when subclassing one needn't know about the existence of cuts, but I'm now
wondering whether it could be a problem in some cases when the aspect should
really stay external to the implementation of classes... Do you have a way to
solve that problem already?

> Note: if you use the patch, the keyword 'cut' is named '__cut__'. This is
> because the Tk library uses 'cut' as a method name and it fails the tests
> otherwise.
>

I hope this small problem won't prevent the RCR to be accepted.
--
Christophe Grandsire.

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.