I guess the conversation has come full circle... I think it comes down to a decision between a) doing nothing and having to work around the problem in awkward ways and b) implimenting something that either breaks existing behavior (true null) or acts inconsistently (null value that is comparable to itself but acts like a zero in all other ways).
My biggest problem in all of this is that there's no way to differentiate between an integer that hasn't been specified (UNDEFINED or nil) and one whose value is simply zero. I think the introduction of UNDEFINED was bound to cause it to be misused, especially since a) there's a gap here in the language that (right or wrong) many other languages don't have and b) the discussion introducing UNDEFINED suggested it had a nil-like quality when used as an argument to methods.
It's further complicated by the multiple identities of zero: both 0 == UNDEFINED and 0 == 0 are all true... that's why I suggested that there be a new zero type to signify a value that's not been set, and have it be NULL or something. It would also be nice if UNDEFINED == UNDEFINED were true and 0 == UNDEFINED were false, but I haven't thought through all of the implications of that. It certainly would break some existing behavior that rely on that initially set value acting as a zero. It's probably enough to be able to query specifically the "intent" rather than to have comparisons look at the intent (undefined, index not present, object destructed).
Additionally, as I think some has mentioned, it's fine to have abstractions use their own entities for things like NULL and true/ false, but a big problem is that pike doesn't have a way to express these things that don't overlap with another datatype (is a zero 0, or null or false?).
Anyhow, I guess I don't have anything more to contribute.
Bill
On Nov 24, 2007, at 12:20 AM, Johan Sundström (Achtung Liebe!) @ Pike (-) developers forum wrote:
I don't agree, perhaps not strongly, but still not. Having the same null for different context is no better than having the same 0 in different contexts.
My point is that it's exactly as good (neither better nor worse): zero is zero, so you should not define a cache API that is supposed to be able to store a zero and assign zero any out of bounds semantics, as is the case with zero_type adding an out of bounds data property you can ostensibly inspect. To see if it's in the cache, add a test method returning a bool. For mappings, the name of this method is has_index.
Substitute "null" for zero above and strike the bit on zero_type, and the same argument holds. Null is null, no more, no less.
Context switching back to the zero_type topic from the unrelated null topic, I think my response to the difficult problem is that 3 is best, 1 acceptable and (after hearing Mast's thoughts) 2 senseless.
!DSPAM:4747b5a7258865209328925!