Front page | perl.perl5.porters |
Postings from September 2022
On Sat, 17 Sept 2022, 11:57 Paul "LeoNerd" Evans, <leonerd@leonerd.org.uk> wrote: > On Sat, 17 Sep 2022 03:53:53 -0700 > Darren Duncan <darren@darrenduncan.net> 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? Yves > >Thread Previous | Thread Next