Collection vs Dictionary

[Pavils Jurjans]

Hello,

There's some confusion about the purpose and difference between these handy
classes...

First, both of them are holding number of key - value pairs, right? Then, I
see that there may be some difference in terms of data types allowed for
keys and values, perhaps?

I read the following in MSDN about "CollectionBase " class and
"DictionaryBase " classes:
CollectionBase: Provides the abstract (MustInherit in Visual Basic) base
class for a strongly typed collection.
DictionaryBase: Provides the abstract (MustInherit in Visual Basic) base
class for a strongly typed collection of key-and-value pairs

Hey, this implicitly signals that Collection is *not* collection of
key-and-value pairs, which is certainly not true. Then what's the truth?

The System.Hashtabl e class seems to be the most flexible representative of
Dictionary classes, having both key and value types "object". Would that
imply that if either key of value type is anchored to one specific, it is no
more to be called "Hastable"?
-- Pavils

[Pavils Jurjans]

Hello John,

Wrong. Collections only need to be collections of values - no need for
keys.

I am confused about this denial... Say, NameValueCollec tion class. It's a
collection, right? But there's a key-and-value information inthere, true?

The following code writes all the *keys* withing the NameValueCollec tion:

foreach (string y in x)
{
Console.WriteLi ne(y);
}
As Jay comments down there in this thread, "...I was a little surprised that
the For Each returned a string instead of a DictionaryEntry .". Would that be
a collection, or as it was defined, "a pile of stuff, not a list of keys and
corresponding values", it would consist of key-value pair objects. Or is
that just a specific implementation of NameValueCollec tion enumerator here?

Confused,

Pavils

[Jon Skeet [C# MVP]]

Pavils Jurjans <pa****@mailbox .riga.lv> wrote:

Wrong. Collections only need to be collections of values - no need for
keys.
I am confused about this denial... Say, NameValueCollec tion class. It's a
collection, right? But there's a key-and-value information inthere, true?

Yes. Just because there's I said there's no *need* for a collection to
have keys doesn't mean there *can't* be keys.

Proof of my statement is pretty simple though - ArrayList implements
ICollection, and there are no keys in that. Hence a class doesn't need
any concept of "key" to be a collection.
The following code writes all the *keys* withing the NameValueCollec tion:

foreach (string y in x)
{
Console.WriteLi ne(y);
}
As Jay comments down there in this thread, "...I was a little surprised that
the For Each returned a string instead of a DictionaryEntry .". Would that be
a collection, or as it was defined, "a pile of stuff, not a list of keys and
corresponding values", it would consist of key-value pair objects. Or is
that just a specific implementation of NameValueCollec tion enumerator here?

It's actually the NameObjectColle ctionBase's implementation of
GetEnumerator - and while it's surprising in that other mapping
collections act as a collection of DictionaryEntri es in this sense, the
documentation for NameObjectColle ctionBase.GetEn umerator does spell out
what it does:

<quote>
This enumerator returns the keys of the collection as strings.
</quote>

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too