Front page | perl.perl5.porters |
Postings from June 2022
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?
Eirik
Thread Previous
|
Thread Next