in reply to Re: RFC: Sub::Prepend - Prepend code to named subroutines
in thread RFC: Sub::Prepend - Prepend code to named subroutines

Your* knowledge of English exceeds that of the average native speaker. Can't even see any accent from here.

To the point, I would agree that 'prepend' is somewhat lacking. That implies a permanent attachment. I haven't got any ideas that I particularly like, but maybe you** could generate something out of 'pre', 'sub', 'hook', 'trap', and 'call' in some combination.

*moritz, **lodin

sas
  • Comment on Re^2: RFC: Sub::Prepend - Prepend code to named subroutines

Replies are listed 'Best First'.
Re^3: RFC: Sub::Prepend - Prepend code to named subroutines
by lodin (Hermit) on Jun 05, 2008 at 18:22 UTC

    Actually, both the implication of permanent attachment and spatial rather than temporal seem to fit. The first is clear cut--it is a permanent modification, unlike some of the other modules that support unwrapping.

    The second is more of how you think about it. I think about it as a code block that's inserted at the very beginning, i.e. "as a string", so

    prepend foo => sub { # Remove the invocant. shift; }; sub foo { print shift; }
    is equivalent to
    sub foo { { # Remove the invocant. shift; } print shift; }
    That doesn't mean I'm set on prepend. Spelled-out suggestions are still welcome.

    lodin

Re^3: RFC: Sub::Prepend - Prepend code to named subroutines
by hsmyers (Canon) on Jun 06, 2008 at 08:06 UTC
    While I don't mind ::Prepend as it seems accurate given the problem space, perhaps ::Prefix might lessen the vocabulary curve without too much precision loss?

    --hsm

    "Never try to teach a pig to sing...it wastes your time and it annoys the pig."