Well... It means that I cannot test something for equality to UNDEFINED and expect correct results (when value is present but is integer zero).
So UNDEFINED by itself is useless, unless tested by zero_type().
It would be nice to have universal "void" value, which would be tested like (value == VOID) where 0 is guaranteed not to be VOID (because it actually isn't).
I don't exactly understand what you want to have - do you want something that means "NULL" but which isn't zero and if you do NULL == <zero or variable with value zero> to always return false?
/ David Hedbor
Previous text:
2003-01-22 06:59: Subject: Re: zero_type() & UNDEFINED and _typeof()
On Wed, Jan 22, 2003 at 03:00:00AM +0100, Johan Sundström (a hugging punishment!) @ Pike (-) developers forum wrote:
whereas 4 != 5. zero_type() tests a a property that `== does not see.
Well... It means that I cannot test something for equality to UNDEFINED and expect correct results (when value is present but is integer zero).
So UNDEFINED by itself is useless, unless tested by zero_type().
It would be nice to have universal "void" value, which would be tested like (value == VOID) where 0 is guaranteed not to be VOID (because it actually isn't).
And "zero_type" is not really meaningful name for such testing (at least out of Pike context)... So I'll alias it to undefined() :)
What is more interesting:
mixed x, y; x = 1;
(16) Result: 1
y = 2;
(17) Result: 2
_typeof(x);
(18) Result: int(1..1)
_typeof(y);
(19) Result: int(2..2)
But:
sprintf("%t", x);
(20) Result: "int"
sprintf("%t", y);
(21) Result: "int"
What a surprise... :) It was just a curiosity, but results are impressive, I didn't expect that two integer values may have different type :)
Regards, /Al
/ Brevbäraren