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

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.

  • Comment on Re^5: Module callbacks - to fork or not fork

Replies are listed 'Best First'.
Re^6: Module callbacks - to fork or not fork
by kcott (Archbishop) on Mar 02, 2023 at 11:22 UTC

    Thanks for providing the clarification.

    I can understand avoiding CPAN modules that require additional (non-Perl) libraries, have complex dependencies, or even those that need a C compiler to handle XS code. Beyond that, I wouldn't not use a CPAN module simply because it's not core.

    Ref::Util will use XS code if a C compiler is available; otherwise, it falls back to pure Perl (see the last dot point in the DESCRIPTION). Other than that, it only has a handful of core module dependencies (see its Makefile.PL).

    — Ken