D5 - congrats and a question

Andy and Blair,

Congratulations on the release of D5!!

Dictionary no longer allows nil keys.  Why the test/error?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:aausbm$e2nap$[hidden email]...
> Andy and Blair,
>
> Congratulations on the release of D5!!
>
> Dictionary no longer allows nil keys.  Why the test/error?

Because LookupTable/IdentityDictionary store the (key,value) pair in
parallel arrays, rather than an array of Associations, and they use nil to
mark empty slots in the key array making it impossible to distinguish a nil
key from an empty slot. LookupTable and Dictionary are interchangeable for
the majority of requirements for a "map" (though we tend to use the former
because it is more efficient), so it seemed preferable to disallow nil keys
for both rather than introduce an inconsistency.

Regards

Blair

Blair,

> Because LookupTable/IdentityDictionary store the (key,value) pair in
> parallel arrays, rather than an array of Associations, and they use nil to
> mark empty slots in the key array making it impossible to distinguish a
nil
> key from an empty slot. LookupTable and Dictionary are interchangeable for
> the majority of requirements for a "map" (though we tend to use the former
> because it is more efficient), so it seemed preferable to disallow nil
keys
> for both rather than introduce an inconsistency.

Does ANSI specify the "correct" behavior?  It seems that somewhere one would
want to have the option to associate something with nothing, or perhaps with
nil as the singleton UndefinedObject.  I remember hitting the same issue
with SharedLookupTable, and just hacked around it; in that case, I really
care about nil as "just another object".  The code that blew up today can be
altered, but, a Dictionary that happens to have a nil key really seems to
fit the problem.

Anyway, it sounds like I can safely remove the check to get things going??

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:aav7d8$e1dpd$[hidden email]...
> Blair,
>
> > Because LookupTable/IdentityDictionary store the (key,value) pair in
> > parallel arrays, rather than an array of Associations, and they use nil
to
> > mark empty slots in the key array making it impossible to distinguish a
> nil
> > key from an empty slot. LookupTable and Dictionary are interchangeable
for
> > the majority of requirements for a "map" (though we tend to use the
former
> > because it is more efficient), so it seemed preferable to disallow nil
> keys
> > for both rather than introduce an inconsistency.
>
> Does ANSI specify the "correct" behavior?

Yes, in a way. It specifically says that it is "undefined" :-). This means
that regardles of what the "correct" behaviour might be from an intellectual
perspective, the different dialects at the time of its writing adopted
different rules so it was deliberately left unspecified. Dolphin XP, like
VisualWorks, treats it as an error. Past Dolphin versions did not explicitly
treated as an error, but it did result in "undefined" behaviour.

Regards

Blair