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:
Salvador Fandiño
Date:
March 9, 2022 09:10
Subject:
Re: Pre-RFC: builtin:: functions for detecting numbers vs strings
Message ID:
a569d5dd-481a-3482-94ba-7e4ee4db6d0f@gmail.com
On 8/3/22 17:25, Karl Williamson wrote:
> 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

It has just occurred to me that we may be missing the point focusing in 
that it-was-created-as-a-whatever thing too much.

If a scalar was created as, say, a number, it keeps being a number. That 
perl is able to transparently convert that value into something else 
when needed and cache the result, doesn't change the fact that it is 
still a number.

 From a functional point of view, I think that was is needed is a set of 
functions to check the type of a scalar and another set of functions (a 
la looks_like_number) to check whether it can be converted into 
something else:

   builtin::isa_number
   builtin::looks_like_number
   etc.

One important point here is that neither "isa_number", neither 
"looks_like_number" are influenced by the private type flags (or the 
scalar history, which is an uninteresting thing, right?):

   $a = "7";
   say isa_number($a), looks_like_number($a);
   $b = $a+1;
   say isa_number($a), looks_like_number($a); # same results


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