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

Re: module loading built-in

Thread Previous | Thread Next
From:
Felipe Gasper
Date:
September 12, 2021 16:22
Subject:
Re: module loading built-in
Message ID:
058BE66D-703A-4B3A-AA28-3ACAA2BC2499@felipegasper.com


> On Sep 12, 2021, at 12:11, Graham Knop <haarg@haarg.org> wrote:
> 
> 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.

If I may, another suggestion/request: have the built-in return the namespace itself. This way it’s easy to do stuff like:

my $class = 'My::Class';
my $thing = need($class)->new();

-FG

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