I guess what I'm really after is a psuedo strong type casting option for variables. In other words, if I used a scalar in string context, I want to be warned if I later use it as a number (even if it looks like a number).

Then you shouldn't have used Perl to begin with. This automatic casting between numbers and strings is a feature, just as it's considered a feature in C that if you divide a float by an integer, the integer is casted to a float.

Also realize that in Perl, that any checking of the form "is this a number" has to be done at run-time (unlike the typechecking in C that can be done in compile time). You really don't want to do a check for each operation, the slowdown would be noticeable. You get the "Argument 'foo' isn't numeric" for 'free', because Perl needs to convert the string value to a numeric value, and the C library functions strto* will flag failure. You will notice that you get the warning only if Perl hasn't attempted to translate the string value to a numeric value - if Perl already did this (unsuccesfully), you don't get a warning.

Abigail

My main use for Perl is Web based applications, so the only other alternative is PHP and I don't consider that to be anywhere near as stable besides anything else.

This check wouldn't have to be done at run-time - a separate "lint" program would do. I'd really only want to use the "ultra pedantic" check after completing a large section of code, not every time it was executed.

Excuse me? Where does it say that you can only use Perl or PHP to do Web based applications? Java, C, C++ and many other languages can be used as well, without any problems.

And yes, the check does have to be done at run time, because only at run time one can know what's in a variable. Unless you've solved the halting problem, but then you wouldn't be writing web applications.

Abigail

Technically, you cannot check the run-time usage of your variables concerning strings/numbers in compile time (or before, using 'lint' or somesuch) with a garrantee of success, because you don't have any idea of what data your program will read in from external sources. (Keyboard, files, databases, etc.)

So even if your code compiles without any 'numeric/string warnings' it may still fail in runtime when handling unforeseen data.

I guess the reasoning goes something like: "Since we cannot garrantee a successful verification in compile time but the programmer must anyway do it in run-time when it's important, then le'ts be consistent and let the programmer do the verification whenever s/he thinks it is necessary."

Personally, I tend to agree.

---

Everything went worng, just as foreseen.

This seems reasonable to me. Just assume that any time you do math with strings, or string operations with numbers that perl silently handles the type conversions required. So the below

>perl -e "print 1 . '1' + '.01'"
11.01
[download]

>perl -e "print str2num(num2str(1) . '1') + str2num('.01')"
[download]

Dont knock it, eventually youll wonder why it isnt this easy in all of the other languages...

;-)

--- demerphq
my friends call me, usually because I'm late....