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:
Yuki Kimoto
Date:
March 18, 2022 01:36
Subject:
Re: Pre-RFC: builtin:: functions for detecting numbers vs strings
Message ID:
CAExogxMTekT+YOLO3LPHwQOVuKYhBDv_w+n0FKMMrksQX+F0NA@mail.gmail.com
2022-3-18 0:50 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

> On Tue, 15 Mar 2022 14:55:06 +0900
> Yuki Kimoto <kimoto.yuki@gmail.com> wrote:
>
> > This is because I don't know the cases that the value is changed after
> > "started".
> >
> > A value is started as a number (3). If the value is used as a string,
> > "3" is maybe cached to the pv slot.
> >
> > A value is started as a string ("3"). If the value is used as a
> > number, 3 is maybe cached to the nv or iv slot.
> >
> > As Darren says, Is the value classified to a string or a number from
> > the starting to the destruction, not only starting?
>
> Indeed, this is the point of the core perl change, to make the public
> flags reliable and fixed after the value is created. We can now use
> those flags to reliably answer questions about the origin of a value,
> irrespective of any additional cached parts the value has gained as a
> side-effect of being looked at since then.
>
>
If this description is documented well in "created_as_number" and
"created_as_string" functions ,
I don't oppose the names "created_as_number" and "created_as_string"
strongly.

The features are no problem.

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