Nick Ing-Simmons wrote:
> > Another possible reason for the behaviour is: this used to be an > internals thing (like many things now in the API), and > was used to test if numeric compare e.g. $foo == $bar made sense. >
I was thinking that the function was still being used internally for such sanity checks. ie I assumed the reason that '$aref *= 2' didn't produce a warning was that 'looks_like_number()' returned true for $aref. I wouldn't be greatly surprised to learn that some entirely different mechanism is being employed.
> if ($aref == $bref) # sane >
Hadn't thought of that - but, yes, it *is* sane.
However, $aref *= 2 is insane, and it seems incongruous to me that such insanity escapes without a warning - not that I have a remedy for such incongruities, needless to say :-)
A week or so ago, someone posted to the Inline mailing list wanting to know how to check that an argument passed to an Inline C function was numeric. This person wanted IVs, UVs, NVs and PVs (that were valid number strings) to be accepted, but anything else to be rejected. I immediately thought of 'looks_like_number()' and replied to that effect. I then found that 'looks_like_number()' also returns true for RVs and posted an amendment. It has been nagging at me ever since because it seemed to me that 'looks_like_number()' *ought* to meet the original poster's needs, but did not.
Well .... I guess, after all, the function *is* named 'looks_like_number', and not 'actually_meant_to_be_a_number'.
Thanks for the clarifications muppet, Nick.
Cheers, Rob
--
Any emails containing attachments will be deleted from my ISP's mail server before I even get to see them. If you wish to email me an attachment, please provide advance warning so that I can make the necessary arrangements.
