New `mro` method trait

[stevan]

NOTE

This is from an email sent to me by Pete A., it is his idea, but I really like it. – Stevan

---

In Common Lisp there is custom method combination in the MOP where you can customize how methods are combined.

e.g. to call methods in a different order, merge return values (e.g. a "gather" method combination where all overloads are called and collected into a list, a "sum" method combination where all overloads are called and summed together), etc:

(defgeneric activate (item)
    (:method-combination append :most-specific-last)) ; this crap here

It seems to me that what is currently implemented with p5-mop submethods today could instead be implemented through a mro() trait that implements custom method combination rather than use a special case "submethod" keyword for it.

e.g.

class UNIVERSAL {
    method BUILD is mro(ctor_combination) # e.g. no call next method, all methods are called in reverse C3 order
    method DESTROY is mro(ctor_combination) # e.g. no call next method, all methods are called in C3 order
}

"is mro()" explicitly specifies C3 method combination.

If no "is mro" trait is specified in any of the linearizations, it defaults to C3.

It there are any collisions of method combinations between overloads, it is an error.

[phaylon]

Something similar to this can also be found in the accumulator callback for GObject signals: https://developer.gnome.org/gobject/stable/signal.html#signal-registration and seems quite useful.

[stevan]

Class::Std had it as well https://metacpan.org/pod/Class::Std#Method-traits-that-can-be-ascribed

[doy]

This is actually pretty similar to something Yuval and I were discussing at the hackathon in Norway, although we never really came up with anything concrete. If I remember correctly, we were initially discussing it in the context of figuring out if there was a way to make role conflict resolution more of an automatic process (this was back when I had roles as part of the MRO), but then saw that it really would generalize to method shadowing with inheritance as well. I think this is something that will require some thought in order to do properly though - I don't think that something that is only useful for BUILD/DEMOLISH is going to be something worth breaking out as an explicit abstraction.

[stevan]

@doy - traits are cheap and do not add to the complexity of the core, it is worth some deeper investigation perhaps.