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

Re: Pre-RFC: A built-in ability for lexical import/export

Thread Previous | Thread Next
From:
Eirik Berg Hanssen
Date:
June 27, 2022 20:48
Subject:
Re: Pre-RFC: A built-in ability for lexical import/export
Message ID:
CAHAeAG7A1C+041DKsBPKTO7Sc+PqAduVqC4gBrgzSZMF9aVYzw@mail.gmail.com
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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About