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? 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. > 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.Thread Previous | Thread Next