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

Reply via email to