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:
Veesh Goldman
Date:
June 28, 2022 09:32
Subject:
Re: Pre-RFC: A built-in ability for lexical import/export
Message ID:
CAO-W_8BmeuNMSptQ2OYZ6E5aN-OzK=+MBkeFOY32T6-4rsVD8A@mail.gmail.com
On Tue, Jun 28, 2022, 11:53 Ovid <curtis.poe@gmail.com> wrote:

> On Mon, Jun 27, 2022 at 7:28 PM Dan Book <grinnz@gmail.com> wrote:
>
>> I'm concerned about this. Lexical import is designed to limit things to
>>> the current scope and not expose them to the outside world. Because you're
>>> exporting a reference, it's effectively a global variable. If more than one
>>> bit of code imports that reference and alters it, other bits of code might
>>> have already taken decisions based on that data, but the assumptions it
>>> relied on are no longer true.
>>>
>>> I don't entirely agree. It's no different in semantics to passing a
>> variable to a function, which then has an alias to the variable to operate
>> on
>>
>
> I agree with that. What I'm saying is that we shouldn't *add* to the
> issue. At least if you export a sub which returns the data structure
> itself, you have the option of cloning that structure or marking it
> read-only.
>
> If we export variables, they would be much safer if they were read-only by
> default, but with an option to mutate (e.g., you have to ask for the lack
> of safety instead of making it the default):
>
>     lexically_export '$VAR' :mutable => \my $scalar
>
> Otherwise, my vote would be to not support exporting them.
>
> Best,
> Curtis "Ovid" Poe
> CTO, All Around the World
> World-class software development and consulting
> https://allaroundtheworld.fr/
>

In all of these examples, you're actually exporting lexical variables in
the scope of the import sub. None have the issue that you're worried about,
every call to the import routine gets its own variable.

If someone were to decide to export a variable with package scope, or a
state variable, then that's their choice. We can't stop them from exporting
an lvalue subroutine wrapper around such a variable, so there's no way to
fully guard against this problem.

I find this useful for exporting a lexical variable which has a scopeguard,
or for exporting a mock object with a test.

Please don't hold up a very useful feature with concerns that don't have to
do with it.

> <https://allaroundtheworld.fr/>
>

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