develooper Front page | perl.perl5.porters | Postings from September 2021

Re: PSC #034 2021-08-20 - "Namespaces Special"

Thread Previous | Thread Next
From:
demerphq
Date:
September 2, 2021 08:36
Subject:
Re: PSC #034 2021-08-20 - "Namespaces Special"
Message ID:
CANgJU+V-6epxAFLhW37i9EZruGgv9m6K9-2bqaHLycZWygEDoA@mail.gmail.com
On Wed, 1 Sept 2021 at 02:50, Yuki Kimoto <kimoto.yuki@gmail.com> wrote:

> demerphq. Thank you for your reply.
>
> I would like to confirm with an expected example.
>
> Perl 5.40 implements the following functions.
>
> builtin::foo
> builtin::bar
> builtin::baz
>
>   use v5.40;
>

The intersection of "use v5.40" and the builtin namespaces isnt well
defined yet. Personally I would expect it to imply: `use builtin v5.40;`
eg, it would NOT import any subs into the existing namespace, only make
sure that the builtin namespace is properly populated with the subs from
5.40. We didnt discuss this intersection in /too/ much detail, so I would
have to defer to the others from the call but to me its hard to imagine
that combining it with the import form would be helpful, as I can easily
imagine someone saying "I need a way to assert im on the right version, but
I dont want my namespace messed up". For instance, imagine we add some new
control keywords to the language. Those CANT be represented by builtin's so
they need to be tied to features or the version. But we also add some new
functions. I would expect that I can have a way where I get access to the
keywords, but do not want to pollute my namespace with the new functions.
So I expect that use v5.40 would NOT import functions but it would ensure
that they are available.

The whole point of the builtin mechanism is to provide a way to eliminate
surprise and controversy when we add new functions to the language. Much of
the debate is predicated that the functions will have some cost on
developers, and much of this cost is related to those functions being tied
to versions and being forcibly injected into every namespace. By decoupling
the addition of new functions from the namespaces they will occupy we
sidestep this controversy.  I think few would object to the language
receiving a new function they personally will not use, provided they never
need to worry about it at all.


>
>   # OK
>   builtin::foo
>   builtin::bar
>   builtin::baz
>
>   # Not OK
>   foo
>   bar
>   baz
>

Yeah, that is my expectation. If you wanted to do foo without the namespace
qualifier you would explicitly say

use builtin v5.40 qw(foo bar baz);


> Perl 5.42 decides builtin::foo should be into CORE namespace.
>

I assume that when you say the CORE namespace you mean globally available
in all namespaces. If so then I personally would say that we would never do
that. The whole point of the builtin namespace is so that we *stop* having
functions that are injected into your namespace and which might break
backwards compatibility. With the builtin namespace (reminder "builtin" is
at this point purely a placeholder for whatever name is eventually chosen),
all new functional additions to the language are insulated from breaking
code, AND we provide a clean mechanism for people using older perls to
obtain the equivalent functions in their older perls so they can run more
modern code. Eg, we want to as much as possibly disconnect the perl version
from the subs that are available, and whether having them available could
break any code, either backward or forward compatible.

So I cant imagine any reason why would move something from builtin to CORE.
In fact I would say that one we have builtin I cannot see any reason we
would add /anything/ to CORE at all, maybe there are arcane reasons why
some special function might *have to*, but any true function should never
be added to the language via CORE, there is simply no need to do so at all.

NOTE, everything I say here is my interpretation of the consensus we had in
the call about the namespaces, obviously I dont speak for the entire
community and others might see it differently, but I believe I am not going
to far out on a limb with this. I mean, turn it around, if we have a
function in builtin why would we move it into CORE? What would we gain
besides headaches?

cheers,
Yves




-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

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