Front page | perl.perl5.porters |
Postings from May 2021
Re: Namespaces (was Re: Revisiting trim)
Thread Previous
From:
demerphq
Date:
May 29, 2021 06:50
Subject:
Re: Namespaces (was Re: Revisiting trim)
Message ID:
CANgJU+W6fH7obygEBYfNFYPOi3+j8AH-0nGXyAHaQwE5rfLuSg@mail.gmail.com
On Fri, 28 May 2021 at 12:34, Tom Molesworth <tom@binary.com> wrote:
>
>
> On Fri, 28 May 2021 at 17:27, demerphq <demerphq@gmail.com> wrote:
>>
>> On Thu, 27 May 2021 at 19:20, Nei
>> The second category is how they are added to the language. I care
>> about this a lot more than the namespaces we use. I don't think we
>> should use the as currently implemented "feature" mechanism for these
>> keywords, and I think we should think carefully about choosing
>> implementations that cannot be provided in a transparently backwards
>> compatible way. What I would like is that we can somehow say:
>>
>> use keyword "string::trimmed" => "trimmed"; # it would be nice if
>> we could use "as" instead of "=>" here, but it wouldnt be back-compat
>>
>> and have keyword do the magic of determining if we are on a perl that
>> contains string::trimmed and exports it as "trimmed", and if we are
>> not, it loads the module which "supplies" string::trimmed (and which
>> is responsible installing trimmed into the "string" namespace), and
>> then does the require export.
>
>
> Why not use the existing import functionality for this?
Yes, after I posted it occurred to me I should have addressed this. I
agree at first blush there is no need for keyword.pm, one could
achieve nearly everything I mentioned without it.
However, I believe there is a good reason to have it. First it
provides a shim layer where diagnostics can be issued. If you use a
module and its not present Perl gives you a message that maybe you
mistyped, maybe you didnt have the module installed etc. Whereas we
could it make it produce better error messages specific to this case.
It also provides a place where we can have a canonical list of the new
functions, their behavior available to older perls.
A second reason is IMO is that this is a /little/ different from a
normal module load scenario, as IMO we want these loads to only happen
if the perl internals arent set up.
The third reason is I believe that to maximize utility it should be
possible to import these subs under different names. People are
bikeshedding "trim" versus "trimmed". If we make keyword have a built
in "import under a different name" functionality then IMO *that* issue
goes away, and not that our existing official import mechanisms do not
explicitly support this.
> e.g. `use string qw(trimmed ltrimmed rtrimmed rot13ed)` to make things available in the current namespace, or maybe something like `use string qw(:trimmed)` to ensure that the functionality exists as fully-qualified `string::trimmed`?
>
> That'd allow backward compatibility for any existing perl version if the `string.pm` module were to be made available on CPAN. It'd presumably need to be dual-life and the built-in should _not_ apply a default value to $INC{'string.pm'}, since the CPAN version might pull in additional functions that were not available in the core Perl keyword list.
Like I said, I think we *want* the ability to remap names as it
defuses the passions our community has to fight over the very best
possible name. If the API trivially lets you set it up as an alias
then people can map it to whatever they like. If someone wants to
import string::trimmed as
"remove_the_whitespace_from_front_and_back_from_string()" then IMO let
them.
Also I think there is a conceptual difference between a function who's
definition is owned and controlled by the Perl core dev team, and a
function exported by an arbitrary module into an arbitrary namespace.
Any person familiar with a modern Perl should be able to access
exactly the same functionality in older perls, there should be no whim
of the community involved once the API has been baked. So I think we
want to distinguish these things.
BTW I do agree, beyond better error messages and having a well defined
way to get the documentation for the latest functions installed into
my older perl, everything I deeply want /could/ be provided by the
existing import mechanisms along with some support social conventions.
But I feel that that is not a strong foundation for the future. I feel
we have the opportunity here to dream of how things /should/ work
(with the constraints of maximal back-forward-compat) and not restrict
ourselves to how they /could/ work, especially if doing something
different would lead to a better future.
Also I was thinking that /maybe/ we would arrange for keyword.pm to
load the code in a slightly different way than a normal module load,
so that there is no "import" function available. IMO if you are using
something that comes baked in with Perl there shouldnt be an import
function. With keyword in the way we can ensure that when we load the
implementation module we load it via a require without calling any
import method on the loaded module. We would call the import method in
keyword, but not an import method in the implementation module of the
function/namespace.
>>
>> I believe that the perl docs have specified that single word lower
>> case pragamatta names are reserved for Perl internals use.
>
>
> There are a few CPAN modules uploaded as pragmata - curry.pm for example - because the perlmodlib wording isn't quite strong enough to claim them for *internal-only* usage:
>
> > Perl informally reserves lowercase module names for 'pragma' modules like integer and strict.
>
Ok, but this seems like pretty safe territory to stake out for future
perl internals use as compared to any other namespaces where there
were no restrictions at all.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous