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

Re: Pre-RFC: "builtins" namespace

Thread Previous | Thread Next
From:
H.Merijn Brand
Date:
October 7, 2021 10:04
Subject:
Re: Pre-RFC: "builtins" namespace
Message ID:
20211007120417.64228de8@pc09
On Fri, 10 Sep 2021 19:46:35 +0100, "Paul \"LeoNerd\" Evans"
<leonerd@leonerd.org.uk> wrote:

> Hi all,
> 
> Following up our recent "Namespaces" chat, I'd like to get the ball
> rolling on the subject of the builtin functions namespace idea.
> 
> I propose to write an RFC to outline the overall mechanism, and give
> an *initial* list of functions to include in it. I say initial,
> because the entire point of the mechanism is that's where we'll be
> adding any of the "simple, acts like a function" things in future, so
> this very much doesn't need to be a full complete list; just a few
> bits and pieces to get us started.
> 
> To that end I am looking for answers to such questions as:
> 
> 
>   * What should it be called? Votes on:
> 
>       use functions 'abc', 'xyz', ...;
>       use function ...;                 # because  function::abc reads
>                                           nicer
> 
>       use builtins ...
>       use builtin ...

'builtin' gets my vote FWIM

>       use std ...
> 
>     This name would have to be well-behaved as a regular CPAN module,
>     because the module needs to be dual-life, available to install
>     from CPAN so older perls can still use the functions it contains.
> 
>     I therefore feel it should be a single toplevel name, and
>     all-lowercase. I have no strong thoughts about singular vs. plural
>     as a name.
> 
> 
>   * What *initial* set of functions to put in it? [again see comment
>     above]. So far I'm thinking:
> 
>       trimmed($str)   # which started this whole discussion off

even though it is the reason this RFC was started, it is the funtion I
would least care about and use most rarely

>       refaddr($ref), reftype($ref), etc... # from Scalar::Util

yes, please

>       getcwd()  # Seriously, because currently we have one in
>                   Internals:: of all places, and that really needs to
>                   disappear.

If getcwd (yes, please), consider abs_path or realpath too. I checked a
few scripts that used getcwd, and most also use abs_path too

I know you did not want pet-names added, but to me this falls into the
if A then B expectation. Intuitiveness.

As mentioned in the other thread, I'd consider strptime and timelocal
(being the timelocal_posix variant)

>   * Any other important considerations we've missed

I think it would be the set of functions that complement and/or
complete the existing builtin functions, which is why I mention
timelocal as counterpart of localtime

> Try to keep comments brief - remember this is a *pre*RFC chat of
> "should we write this RFC at all?", rather than fine-tuning inner
> details of the idea. That can be handled separately as comments on the
> actual RFC as it gets written.

-- 
H.Merijn Brand  https://tux.nl   Perl Monger   http://amsterdam.pm.org/
using perl5.00307 .. 5.33        porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org
                           

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