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

Re: module loading built-in

Thread Previous | Thread Next
September 17, 2022 14:02
Re: module loading built-in
Message ID:
On Sat, 17 Sept 2022, 11:57 Paul "LeoNerd" Evans, <>

> On Sat, 17 Sep 2022 03:53:53 -0700
> Darren Duncan <> wrote:
> > > I don't see what a builtin would add.
> > >
> > > eval "use $module; 1"
> > >
> > > Works fine.
> >
> > Why?  Its because having to use string eval for something so simple
> > and basic is a TERRIBLE design, a huge code smell.  The proposal of a
> > proper basic runtime-defined load that DOESN'T use string eval is
> > sorely needed.  This is insecure and error prone like SQL injection
> > from straight interpolation of variables into the raw source when it
> > should just be a plain value or argument.
> +1. (Well, +2 if I could ;) )
> Plus also Yves' code didnt' handle errors; you forgot to
>   eval "use $module; 1" or die $@;

I didn't forget anything. I assumed anyone on this list understood that was
implied by the 1. I'm on a mobile phone, typing code is a pita. Sorry I
didn't spell it out.

So all I see is a bunch of folks sticking this load function in an eval.

Whatever, I don't care that much. But please don't call it "load".
"module_load" or "package_load".

I'm a serous anti-fan of lazy loading patterns in library level code,
especially in a web context it is an antipattern that slows things down and
consumes excess memory. I understand and appreciate that for scripts it can
be the opposite. One thing that would sell me on adding this if we came up
with a way to resolve the conflict between those two use cases. Can we
figure out a way that a module consumer can reliably tell modules that they
should *pre*load its dependencies and not lazy load them?



Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About