All- I've been toying with this for a while, and I'm looking for others' input. I'm not RFC'ing it yet because (a) I already have 25 others to maintain and (b) I'm not sure if this might be covered by "my sub" or one of Damian's future RFC's. Currently, there are two big problems in defining subs that override inherited ones: 1. Once you override one, then all classes derived from you get yours by default, and not the parent's. Hence having to have a special dispatch for UNIVERSAL::can and friends if you override them. 2. It is not easy to have them automatically cascaded; you must call SUPER:: (or NEXT::) manually. This becomes a big problem with polymorphic objects, since you might want an ADD routine that just twiddles one thing, but then cascades down (for example, bigint::ADD might override int::ADD, but you might still want int::ADD and UNIVERSAL::ADD automatically called always). The solutions I've been thinking about to these two problems are the following: 1. Make it so a given sub cannot be inherited, for example: sub mymethod : noinherit { } I suspect this may be handled by "my sub", but I couldn't find enough info on p5p to tell for sure. This might also be handled by the "private" keyword Damian proposes, but I couldn't tell for sure. 2. Make it so a sub can automatically cascade and call all subs by the same name in parent classes: sub dostuff : cascade { } I'm pretty sure I haven't seen anything that suggests this yet. Clarification/input/etc is appreciated as always. Thanks, Nate