On Thu, 24 Feb 2022 at 06:54, Darren Duncan <darren@darrenduncan.net> wrote: > On 2022-02-23 9:33 p.m., Dan Book wrote: > > On Thu, Feb 24, 2022 at 12:30 AM Darren Duncan wrote: > > I can completely get behind the idea of properly naming the > functions so that > > their names correspond to their actual meanings. Mainly what I care > about is > > that the functions exist at all, whatever they are called. > > > > On a related note, the original proposed names were for parity with > isbool(). > > So if the new ones are going to have names like > was_input_as_number(), then > > isbool() should similarly be renamed to was_input_as_boolean() or > such. > > Consistency is important. > > > > They don't need to be consistent since they do different things. isbool > returns > > true for only two scalar values which can only ever be booleans. Numbers > and > > strings in general however can become also numbers or strings during > their > > lifetime, regardless how they started. > > "Can only ever"? I had the impression that scalars which started out as > booleans can always be used as either numbers or strings. Or are you > saying > that using a number as a string or vice-versa makes an internal > representation > change for caching purposes (storing both the C int or float plus the C > string > etc) that doesn't happen with the scalars that start out as booleans? On the contrary, a bool false *starts* out being a dual var (that is a PVNV which has a variadic string slot compared to its IV/NV slot) , and a bool true starts out as a fully fleshed PVNV. The magic that makes them bools is that their PV buffer is shared amongst all instances, and is at a well known address (that of the pvs stored in PL_sv_yes and PL_sv_no). It also means the rule that Graham mentioned earlier is wrong, it is not "if the POK flag is set then it started out life as a string", it is "If the POK flag is set and the PV buffer is not the same as the PV buffer in PL_sv_yes and PL_sv_no then it is a string". $ ./perl -Ilib -MDevel::Peek -e'Dump(!0); Dump(!1);' SV = PVNV(0x55b6a3e11158) at 0x55b6a3e0f388 REFCNT = 997 FLAGS = (IOK,NOK,POK,IsCOW,READONLY,PROTECT,pIOK,pNOK,pPOK) IV = 1 NV = 1 PV = 0x55b6a29ff0f3 "1" [BOOL PL_Yes] CUR = 1 LEN = 0 SV = PVNV(0x55b6a3e11138) at 0x55b6a3e0f3b8 REFCNT = 1000 FLAGS = (IOK,NOK,POK,IsCOW,READONLY,PROTECT,pIOK,pNOK,pPOK) IV = 0 NV = 0 PV = 0x55b6a29ff0f5 "" [BOOL PL_No] CUR = 0 LEN = 0 You can answer these questions yourself btw, just use Devel::Peek::Dump and look at the output. In older perls it is similar but the concept of a "bool' having a shared PV slot with PL_sv_yes and PL_sv_no is not implemented. In some rare cases in older unthreaded perls you can "see" a true PL_sv_yes or PL_sv_no. In threaded perls it was always a copy. (You can tell by looking at the refcount.) cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next