Re: Pike 7.8

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!