Note that the new NULL value I'm talking about there is distinct from UNDEFINED. That's necessary since, as I've said earlier, it must be possible to tell whether foo in my_object->foo is a nonexisting identifier or a variable that has the value NULL.
So UNDEFINED has to be a transient value that can't be stored in objects etc, or else it looses its function. (I actually find it a little unnerving that it can be stored in local variables inside functions since that makes it a bit "blurry" conceptually. It's also a bit of a problem when it comes to unification classes and functions, which I think is a very neat idea from a language design standpoint.)
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-23 03:00: Subject: Re: zero_type() & UNDEFINED and _typeof()
On Thu, Jan 23, 2003 at 02:00:01AM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
It'd be even better to make the new zero type not equal to zero and add a new constant nil or null or NULL for it. An uninitialized() function wouldn't be necessary.
Exactly my point. A constant that means that value is not initialized or explicitly deinitialized. This constant must not equals to 0 or anything else but itself. It should be possible to assign this constant to variable of any type, thus "deinitializing" it.
This way, any expression like:
(val = map[key]) != NULL
will give correct result when, and only when the element indexed by key has been set to anything but NULL (including integer 0).
Setting an element of mapping, multiset or array to NULL should delete this element (thus eleminating the need of m_delete()). As of me, the code like:
map[key] = NULL;
seems logical and I expect that element will be deleted.
NULL by itself should be evaluated as "false" in any logical operation.
Pros: we don't need additional function; we can easily check if the result is defined; we can delete elements in natural way (just by undefining them).
Cons: none yet, or? :)
Regards, /Al
/ Brevbäraren