Front page | perl.perl5.porters |
Postings from March 2022
On Wed, 23 Feb 2022 23:03:14 +0100 Graham Knop <haarg@haarg.org> wrote: > 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. ... > 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. 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. We'll leave as an as-yet unanswered question on how these functions behave in the presence of a true dualvar, such as $x = $!; $x = Scalar::Util::dualvar(123, "fourfivesix"); Simultaneously to you hopefully writing that RFC, I'll make a start actually implementing it. The bulk of the work will be in writing the implementation, tests, and documentation, which can happen during any ongoing debate on what the final names should be. Those should be quite trivially simple to fix up afterwards once it's resolved. -- Paul "LeoNerd" Evans leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/Thread Previous | Thread Next