in reply to Re: Module callbacks - to fork or not fork
in thread Module callbacks - to fork or not fork

TIMTOWTDI-others

With Ref::Util you can test it safely, quickly and all-in-one with is_coderef ($maybe_coderef). If you have not already looked at Ref::Util I can wholeheartedly recommend it. Your code will be shorter, less error-prone, faster and arguably more readable/maintainable with it.


🦛

Replies are listed 'Best First'.
Re^3: Module callbacks - to fork or not fork
by Bod (Parson) on Mar 01, 2023 at 23:06 UTC
    If you have not already looked at Ref::Util I can wholeheartedly recommend it

    But Ref::Util is not core...

      G'day Bod,

      "But Ref::Util is not core..."

      You should probably expand on that; as it stands, it's not making a lot of sense to me. This is the first instance of the word "core" in the entire thread. The code you've posted on this site often uses non-core modules: Template, DBI, and many others.

      — Ken

        You should probably expand on that

        Sorry - yes. There is a distinction in my head that I failed to articulate.

        This module is destined for CPAN. I alluded to this by saying it would be used by other people and I have no idea what they might hang on the callbacks. Code that I write, and post here that uses non-core modules is generally for my own internal use, so whether the modules are core or not doesn't matter. What matters is whether I can install them or not!

        Following the release of Business::Stripe::WebCheckout I am really surprised how many people have contacted me about it. So people are using it. I already have working code that deals with Stripe subscriptions and webhooks. I need to use the same functionality on another project so decided to write a couple of general-purpose modules that do the heavy lifting and make those available on CPAN. Hence why, in this case, I would prefer to use core modules.