On Mon, Jun 27, 2022 at 7:48 PM Martijn Lievaart <m@rtij.nl> wrote: > > Op 27-06-2022 om 15:40 schreef Paul "LeoNerd" Evans: > > On Fri, 24 Jun 2022 16:44:27 +0100 > > "Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote: > > > >> I was thinking that maybe it should be just exposed as a builtin:: > >> function itself, perhaps as > >> > >> builtin::lexically_export $name, \&func; > [snip] > What I do not understand is why one would want to use a different > external name than the internal name? Exporter doesn't work like this > and I for one, never felt the need to export under a different name. > There might not even be an "internal name" â the subroutine to be exported might be a closure. I use this in Test::Trap to export trap{} functions with different names, layers, and other options. Although that might be a rather outlandish example ⦠Adapting instead the (oh-so-nostalgic) perlref example of closures, we can imagine: sub import ($class, @colors) { # [ validation? caching? ] builtin::lexically_export $_ => sub { "<FONT COLOR='$_'>@_</FONT>" } for @colors; } No internal name. And yes, this is very rarely useful. Exporter is usually enough, after all. But if you are to offer a generic mechanism for lexical export, is there any good reason to deny programmers this power? EirikThread Previous | Thread Next