Front page | perl.perl5.porters |
Postings from September 2021
On Fri, Sep 3, 2021 at 1:52 PM Salvador Fandiño <sfandino@gmail.com> wrote:
> On 3/9/21 19:29, Felipe Gasper 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?
> >
>
> Instead of a "load" builtin, for searching and loading a module at
> runtime, one supporting just the look-up functionality could be
> provided, so that one could do:
>
> my $mod = "Foo::$bar";
> require module_find $mod;
>
> but also,
>
> my $mod = "Foo::$bar";
> my $mp = module_find $mod;
> if ($mp) {
> require $mp;
> }
> else {
> ...
> }
>
>
The lookup functionality isn't what's missing, just the translation from
valid package name to filename. The lookup is already handled by require/do.
-Dan
Thread Previous
|
Thread Next