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.
| [reply]
[d/l]
[select] |
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.
| [reply] |
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).
| [reply] |