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

Re: module loading built-in

Thread Previous | Thread Next
From:
Dan Book
Date:
September 3, 2021 17:49
Subject:
Re: module loading built-in
Message ID:
CABMkAVUXuZVEtwiS+nynXPSP36jrFHe0xuyh9mwyHfse+t323w@mail.gmail.com
On Fri, Sep 3, 2021 at 1:30 PM Felipe Gasper <felipe@felipegasper.com>
wrote:

>
> > On Sep 3, 2021, at 12:48 PM, Ricardo Signes <perl.p5p@rjbs.manxome.org>
> 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.

-Dan

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About