UNDEFINED is not useless. It's very useful to e.g. use as a return value from a function.
The real problem is that there is no operation "check the existence of the index foo" that is separate from "get the value of index foo". Instead there is this kludge by overloading the value zero with different subtypes. I think the good solution is to add a check for existence operation and then let a zero just be a zero. (The other zero types are fairly obscure and could probably be done away with easily or simply ignored.)
There was a discussion a while back about adding new operators for insert and delete operations, foo+[bar]=gnu and foo-[bar] (something I intend to do when I get the time, unless someone beats me to it). In the same vein an operator for this could be added. The logical choice would be foo?[bar] but unfortunately there was some grammatic problem with that, if I remember correctly.
/ Martin Stjernholm, Roxen IS
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