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

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

Thread Previous | Thread Next
From:
Karl Williamson
Date:
March 8, 2022 16:25
Subject:
Re: Pre-RFC: builtin:: functions for detecting numbers vs strings
Message ID:
1da59782-ef6e-54a2-3708-9af1358b4d37@khwilliamson.com
On 3/8/22 07:38, Graham Knop wrote:
> On Fri, Mar 4, 2022 at 4:29 PM Paul "LeoNerd" Evans
> <leonerd@leonerd.org.uk> wrote:
>>
>> After further discussion with PSC, we'd like to keep moving this
>> forward. There's still time to add new functions to builtin:: in time
>> for 5.36, and it would be nice to get these in.
>>
>> We agree that they should not be named "isnumber" and "isstring",
>> mostly because of your concerns about leading people to think they do
>> something that they don't.
>>
>> I'd like to suggest you write up an RFC on this request, perhaps
>> beginning with the names
>>
>>    builtin::was_originally_number
>>    builtin::was_originally_string
>>
>> They're sufficiently long and unwieldy as to mildly discourage people
>> from using them except when absolutely necessary (read: on JSON
>> serialisers and similar), and the name itself doesn't suggest it tells
>> you current information about the actual type of a value, merely tells
>> you the history on how it started.
> 
> I've created an RFC PR: https://github.com/Perl/RFCs/pull/13
> 
> In the RFC, I'm using the names builtin::created_as_number and
> builtin::created_as_string. Justification is included in the RFC, but
> I think these better match what we want their return values to
> represent. And I personally, was_originally_number feels really
> awkward as a function name. The names could still be changed of
> course; I'm not overly attached to what I've chosen.

I think "created_as..." are better than previous suggestions

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