develooper Front page | perl.perl5.porters | Postings from September 2021

Re: module loading built-in

Thread Previous | Thread Next
Dan Book
September 3, 2021 17:49
Re: module loading built-in
Message ID:
On Fri, Sep 3, 2021 at 1:30 PM Felipe Gasper <>

> > On Sep 3, 2021, at 12:48 PM, Ricardo Signes <>
> wrote:
> >
> > So, let's say we were to implement a new require-like builtin that we
> wanted to be a core language feature and live forever.  Would it be
> something other than something really close to Module::Runtime's
> use_module?  I have some thoughts, but I think the basic question here is:
> >
> > Is it enough to say "v5.x will provide load, which will take a module
> name and optional version, then load that module (or die trying) and call
> ->VERSION on it.
> There’s an opportunity here.
> Occasionally I’ve implemented plugin-like things where I require() a
> module that isn’t actually “required”. To differentiate “no such module
> exists” from “failed to load module” I’ve had to resort to pattern-matches
> on the thrown error, which is ugly.
> I know the topic of structured or otherwise-machine-parsable errors is a
> quagmire, but would it be feasible to implement this new runtime module
> loader in such a way that a caller can reliably differentiate those two
> fundamentally-distinct failure states?

haarg was working on a Module::Runtime replacement that has this capability
with a function called "try_require_module", which returns true on success,
false on not found or insufficient version, and an exception on other
errors. I think it is a great API, but unfortunately has not been put
through the rigors of CPAN workshopping yet.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About