Front page | perl.perl5.porters |
Postings from February 2022
On Thu, Feb 24, 2022 at 12:54 AM 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? > Using one of the true booleans just encoded into builtin:: as a number or string does not change it from being a canonical boolean. In contrast, using '2' as a number changes it to a SV that is both a string and a number, all we are encoding here is what it initially was. -DanThread Previous | Thread Next