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 {
...
}
>
>> 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 {
...
}