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

Re: Pre-RFC: "builtins" namespace

Thread Previous | Thread Next
H.Merijn Brand
October 7, 2021 10:04
Re: Pre-RFC: "builtins" namespace
Message ID:
On Fri, 10 Sep 2021 19:46:35 +0100, "Paul \"LeoNerd\" Evans"
<> 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   Perl Monger
using perl5.00307 .. 5.33        porting perl5 on HP-UX, AIX, and Linux

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