Front page | perl.perl5.porters |
Postings from September 2021
On Fri, Sep 3, 2021 at 6:49 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.
I think a core function to handle this would be a welcome addition.
But I don't think that an equivalent to use_module is enough.
One of the common uses people have for runtime loading is conditional
loading. For example, providing fallback functions if an XS module is
not available. This is often done using something like
if (eval { require Ref::Util::XS }) {
...;
}
The problem with this is that it doesn't distinguish between the
various possible failures when loading the module. It's intended to
catch missing module errors, but it will also catch compilation
errors. This causes problems in debugging, as any later code that
tries to load Ref::Util::XS code will get errors like "Attempt to
reload Ref/Util/XS.pm aborted.", hiding the compilation error.
Currently, Module::Runtime handles optional loading by parsing the
error message given by perl to detect "Can't locate" errors.
This could be considered part of the general problem perl has with its
errors being strings. A proper exception system would allow filtering
these trivially. It could also be considered entirely separate from
loading a stringy module name, since it applies equally to require
with a bareword module name.
A simple "require $module_name" may be the most common case, but I
think optional loading is too common to ignore if we're going to add
this to core.
Thread Previous
|
Thread Next