develooper Front page | perl.perl5.porters | Postings from February 2022

Re: Pre-RFC: builtin:: functions for detecting numbers vs strings

Thread Previous | Thread Next
From:
Darren Duncan
Date:
February 24, 2022 05:54
Subject:
Re: Pre-RFC: builtin:: functions for detecting numbers vs strings
Message ID:
8103ead3-7caa-dbc7-ae79-dad8550b9c89@darrenduncan.net
On 2022-02-23 9:33 p.m., Dan Book wrote:
> On Thu, Feb 24, 2022 at 12:30 AM Darren Duncan wrote:
>     I can completely get behind the idea of properly naming the functions so that
>     their names correspond to their actual meanings.  Mainly what I care about is
>     that the functions exist at all, whatever they are called.
> 
>     On a related note, the original proposed names were for parity with isbool().
>     So if the new ones are going to have names like was_input_as_number(), then
>     isbool() should similarly be renamed to was_input_as_boolean() or such.
>     Consistency is important.
> 
> They don't need to be consistent since they do different things. isbool returns 
> true for only two scalar values which can only ever be booleans. Numbers and 
> strings in general however can become also numbers or strings during their 
> lifetime, regardless how they started.

"Can only ever"?  I had the impression that scalars which started out as 
booleans can always be used as either numbers or strings.  Or are you saying 
that using a number as a string or vice-versa makes an internal representation 
change for caching purposes (storing both the C int or float plus the C string 
etc) that doesn't happen with the scalars that start out as booleans? -- Darren 
Duncan

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