Front page | perl.perl5.porters |
Postings from March 2022
I made good name proposals already: - is_canonically_a_number() - is_canonically_a_string() - is_canonically_a_boolean() -- Darren Duncan On 2022-03-13 8:46 p.m., Yuki Kimoto wrote: > My understanding: > > Perl 5.36+ can detect a string and a number completely. > > a string - SvPOK > a number - (SvIOK or SvNOK) and not SvPOK > > However, we don't want to say these are "is_number" and "is_string" because Perl > used to manipulate a number and a string as the same thing for a long time. > > We search for good names except for "is_number" and "is_string". > > > 2022-2-24 7:03 Graham Knop <haarg@haarg.org <mailto:haarg@haarg.org>> wrote: > > After the merge of https://github.com/Perl/perl5/pull/18958 > <https://github.com/Perl/perl5/pull/18958>, it is > possible to reliably distinguish between values that started as > numbers vs values that started as strings. Essentially, if the POK > flag is set, the value started as a string. If the POK flag is not set > and IOK or NOK is set, it started as a number. These flags can be > checked in XS, or via the B module, but cannot currently be checked in > pure perl. For serializers, being able to detect the original type of > a value is essential, so it would help to provide functions to provide > this information. For example, providing builtin::isnumber and > builtin::isstring, to go along with builtin::isbool. > > This does potentially have a huge impact on the language as a whole. > While this is needed for serializers, providing easy access to this > type data will pretty much inevitably result in people using the > functions within perl for things like parameter validation. The values > "2" and 2 are meant to be fully interchangeable inside perl, and new > code distinguishing them will break many expectations. > > Even with caveats, I do think this is something that the language > should provide. I am uncertain on the naming of the functions. > builtin::isnumber and builtin::isstring are perhaps the most > obvious, but they also imply that distinguishing these types is a > normal thing to do. We may want the function names to be more > opinionated, implying more strongly that they are meant to be used for > things like serialization, not internal type checking. That feels like > a losing battle though once any function of this type is available. >Thread Previous | Thread Next