On Fri, Jun 24, 2022 at 11:44 AM Paul "LeoNerd" Evans < leonerd@leonerd.org.uk> wrote: > One of the offshoots from the Pre-RFC rejections of the `module` and > `UNIVERSAL::import` ideas, was the thought that perl core really needs > to provide some nicer ways to implement lexical import into the > caller's lexical namespace. > > Core didn't really have any code that does lexical import of normal > symbols, so when I created the `builtin::import` function I had to > create it all specially. It's fine there but feels a bit weird not > providing that as a general mechanism for others to use. > > I was thinking that maybe it should be just exposed as a builtin:: > function itself, perhaps as > > builtin::lexically_export $name, \&func; > I can't not suggest "lexport". > Perhaps it should take a whole kv-list of name/ref pairs, so you can > export lots in one go: > > builtin::lexically_export > one => \&one, > two => \&two, ... > > Though maybe it would be bad to encourage that because really the > caller ought to be specifying just a few symbols they want. Hmm. > I don't think it's a big deal, being able to export multiple in one call seems like a good feature. > Also, while syntactically this is written out "like a normal function" > and thus could go in `builtin::`, I wonder if it's a good fit here. It > can only possibly work during BEGIN time, because it affects the > compiletime lexical environment of the code being compiled. It isn't > useful at runtime. It syntactically looks like a regular function but > it doesn't really behave like one. > > We probably do want this available as a core function, but what should > it be named? Is `builtin::` still a good place to put it? > I can see arguments for either way. If we had a namespace for "less normal keywords" then I might argue for putting it there, but under a strict interpretation of "parsed like a normal function", it certainly could fit in builtin. -DanThread Previous | Thread Next