On Wed May 10 20:09:17 2006, Arnt Gulbrandsen wrote:
Dave Cridland writes:
I'm really not so sure. On the face of it, it sounds like bad
design, but I think there's at least two cases here - an attempt
to compare "fish" and "bicycle", and an attempt to compare "fish"
and "2". I have a feeling this is an important distinction.
It is precisely the distinction between "neither input is valid"
and "one input is valid, the other not".
Arguably, "fish" is equal in numeric value to "bicycle" - they
both have no numeric value, so it's the same as comparing NIL and
NIL with "i;octet".
Or as comparing null with null in SQL.
Equally, "2" has a numeric value of 2, whereas "fish" does not, so
they are unequal - like comparing NIL and an existing string with
"i;octet".
Or as comparing 2 with null in SQL. And wouldn't you know, SQL is
different from ACAP in this respect.
Good for SQL... ACAP's definitions regarding this are a lot less
clear.
I'd rather not venture into this dark and confusing maze of
null/nil semantics. These are choices for the protocol to make, say
I.
I think - but I'm not absolutely sure - that the question has already
been settled.
In RFC2244, section 3.4, which is the authoritative definition of
comparators:
1) "i;octet" specifically states that NIL is equal only to itself.
(Second paragraph in its definition, last sentence)
2) "i;ascii-casemap" specifically states that it applies a mapping
then does "i;octet". So NIL==NIL again.
3) "i;ascii-numeric" then complicates my argument, because "All
values which do not begin with a US-ASCII digit are considered equal
with an ordinal value higher than all non-NIL single-valued
attributes" - that certainly seems to mean "fish" == "bicycle", but
I'm not sure if it means "fish" != NIL or "fish" == NIL. It says
nothing to me about whether NIL == NIL.
Instead, I think I'll add a fourth operator, valid, which indicates
whether a given string is valid input for the collation. It's not
really necessary. indomain(a) is true if and only if a=a. But it
sounds sensible. Permits protocols to differentiate between one and
two invalid inputs if they want to, without resorting to hacks like
a=a.
I'm entirely happy to have an additional operator, however, I'd
prefer to standardize the behaviour somewhat. In particular, I'd
quite like it settled as to whether NIL==NIL in general, and whether
invalid input is equal to NIL - at the very least as a default.
Dave.
--
You see things; and you say "Why?"
But I dream things that never were; and I say "Why not?"
- George Bernard Shaw