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

Re: Namespaces (was Re: Revisiting trim) Perl5 Porters<>

Thread Next
Salvador Fandiño
May 28, 2021 13:25
Re: Namespaces (was Re: Revisiting trim) Perl5 Porters<>
Message ID:
On 28/5/21 12:33, Tom Molesworth via perl5-porters wrote:
> On Fri, 28 May 2021 at 17:27, demerphq < 
> <>> 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 
> ` <>` 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{' <>'}, since the CPAN 
> version might pull in additional functions that were not available in 
> the core Perl keyword list.

Going even further, instead of built-ins, those modules can just be 
regular modules that are loaded on demand. So, for instance you can have 
a "" file (and maybe "string.xs") implementing "trim", 
"trimmed", etc. that on newer perls,  would be loaded automatically when 
anything inside the "string" namespace is called.

If the user want to be able to use the unqualified function names, it 
can just do "use string qw(trim)". And he also gets for free the ability 
to do "use string 0.10", to ensure that, say, "string::trimbution()" is 

For backward compatibility, the same module can be distributed in CPAN, 

Under this schema there are only two things to consider:

1) There is no reason why "trim", "trimmed", etc. should be keywords 
instead of regular functions.

2) The module autoloading functionality is needed.

At the end, supposing 2 is not difficult to support, you get an easier 
implementation, better backward compatibility and less cognitive load as 
for the most part you are just reusing regular features.

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About