in reply to Re^2: RFC: Verify Interpreter and Language
in thread RFC: Verify Interpreter and Language

Hmm I don't seem to have made my position clear. What I mean was, occasionally in data, an empty string and NULL are equivalent. Occasionally, 0 and NULL, or 0 and "" are equivalent. Effectively testing this in Perl is a bit of a pain, and in SQL it's even a lot worse because 
SELECT * FROM mytable WHERE foo=foo

[download]
will not show the records where foo is null. Purists might say this is how it should be, but I think it's just not very practical.

It'd be nice if you provided a simple means to test if a value is, say, NULL, 0 or "", perhaps using something like in (as in Mysql): 

if($foo in (0, "", undef)) ...

[download]

I'm actually not even sure that NULL is a valid value for the IN list in Mysql...

Replies are listed 'Best First'.
Re^4: RFC: Verify Interpreter and Language
by exussum0 (Vicar) on Feb 14, 2006 at 18:36 UTC
    I see what you mean. This is what I provide. Give me your opinion on when I can tweak it, or reasons to change it.

    == works on strings and numbers in Verify.

    "" == 0, 1 == "1", "2" == 1+1 would all return true.

    "a0" == 0 would return false, since a0 is not convertable to a number.

    If you refer to a variable that does not exist, the empty string is returned. So doing something like "" == x, where x isn't defined, would return true.

    I'm convinced to add isDefined/isNull, similar to perl's defined.

    p.s. Thanks for the feedback. Whole point is to get some tweaking in on this before I shoot myself in the foot. :)

[reply]
[d/l]

In Section Meditations