Front page | perl.perl5.porters |
Postings from February 2022
On 2022-02-23 9:19 p.m., Dan Book wrote: > On Thu, Feb 24, 2022 at 12:10 AM Darren Duncan wrote: > Maybe string "2" and number 2 are supposed to be interchangeable in Perl, but > users should have the choice as to whether they want them to be interchangeable. > > This is not simply a choice for one programmer to make in isolation. If not done > carefully it has effects on all parts of the code that touches those scalar > values, such as CPAN modules and existing code that was written with a specific > interpretation. As I understand it, all these added functions do is return information on their argument, and they don't modify or have side effects on their argument in any way. And so any one using those functions won't affect the behavior of any code but their own and code which uses their own, which is the same as how things work generally anyway. > The whole idea of denying users functions like builtin::isnumber etc because > they might want to actually use them for things they are well suited for, that > very much goes against Perl's core idea that there's more than one way to do > it, > and is unnecessarily forcing one's personal preferences on others. > > This isn't the argument being made. It's a bad idea to provide it under that > name because it implies something that is not being enforced. If it were > something different perhaps it would make sense but that would require even more > fundamental language changes. 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. -- Darren DuncanThread Previous | Thread Next