Front page | perl.perl5.porters |
Postings from March 2022
On Wed, 9 Mar 2022 at 10:10, Salvador Fandiño <sfandino@gmail.com> wrote: > > 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. No, that is very much the point. Serializers, especially JSON need to know this or they simply do the wrong thing. > 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. Right. But previously we couldn't tell if the number started off as a string or 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. I dont really follow what "isa_number" is compared to "looks_like_number". Is "isa_number" meant to to be the same as "created_as_number" from this proposal? > > 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 I dont get what you want here. The standard definition of looks_like_number() would return the same thing for both lines. I am not sure what isa_number is supposed to do, but if its the same as created_as_number() then it would too. Eg, say would output FALSE, TRUE both times. (For some printed definition of FALSE and TRUE). cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next