Front page | perl.perl5.porters |
Postings from March 2022
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 suggestionsThread Previous | Thread Next