http://www.perlmonks.org?node_id=412588


in reply to Re: Use method/function signatures with Perl
in thread Use method/function signatures with Perl

That's a fascinating thought, I must admit. I'll keep it in mind, though I'm unsure of the best approach for implementation. For the time being, you could use a wrapper subroutine that handles the context for you and have it call the "signified" subs.

Cheers,
Ovid

New address of my CGI Course.

Replies are listed 'Best First'.
Re^3: Use method/function signatures with Perl
by BrowserUk (Patriarch) on Dec 06, 2004 at 08:46 UTC

    No. I can't either. I was initially thinking that as your running at compile time, you could generate a sigified-without-context wrapper sub that detectes the context and dispatched to the sigified-with-context subs.

    And then replicate the user written sigified-without-context subs, to save coder effort and (human) cut&paste code reuse.

    Unfortunately, whilst entirely possible to do, it doen't buy you much as you end up with three version of the same code with different names.

    I tried to think of some way of using the source-filter nature of your module to perform some source-substitution "macro expansion" when generating the 3 variant requirements, but it may be too big a task I fear.

    In the simple case of don't do anything in a void context and return the list or a reference to it in the other two, it's easier, and perfectly efficient to make that determination at runtime.

    For the more complex case, the best idea I came up with is a a trio of pseudo-pseudo-blocks.

    VOID{ ... } SCALAR{ ... } LIST{ ... }

    When munging the subnames in the source filter, you'd also look for these. If the user's sub definition contained one or more of them, then you would generate the signified-without-context dispatcher sub. And one signified-with-context duplicate of the user's sub definition, but with the appropriate pseudo-block label, and the entirity of the other two types of pseudo-block removed. Or a fatal exception catcher for any that didn't exist.

    It apppealed for a while, but I'm not sure that any efficiency gains from the removal of the runtime conditionals would give wouldn't be outweighed by the extra level of dispatch. And whilst the pseudo-blocks would allow the user's source to be fairly clean if the decisions are simple, it could easily get messy if they are more complex.

    Finally, the extra complexity in the source filter would probably make test and validation much harder for production quality to be achieved.

    Oh well. It seemed like a good notion when the thought struck me.


    Examine what is said, not who speaks.
    "But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen
    "Think for yourself!" - Abigail        "Time is a poor substitute for thought"--theorbtwo         "Efficiency is intelligent laziness." -David Dunham
    "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon