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.Hashtable 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

 

[Jon Skeet [C# MVP]]

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?

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

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?

No, it is true - ICollection is *not* a collection of key/value pairs.
It's a collection of values. Where did you get the idea that it's a
collection of key/value pairs?

The System.Hashtable 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"?

I didn't quite follow that sentence, but you can certainly use value
types in hashtables, as either keys or values. They just end up getting
boxed.

 

[Pavils Jurjans]

Hello John,

No, it is true - ICollection is *not* a collection of key/value pairs.
It's a collection of values. Where did you get the idea that it's a
collection of key/value pairs?

My understanding of term "collection" comes from VB, especially programming
with classic ASP prior to transerring all ASP developement to JScript couple
of years ago. So, in classic ASP, for example, I get "A collection of form
variables" in Request.Form object. Since they are readable by providing key,
I was under impression that collection certainly is key-value pair holding
structure. So, as far as I see from your comments, C# collection should not
be confused with VB collection. Soo.. is there a "place" of item within
collection, or it's like a sack with stuff where order of thnks is
irrelevant? I see references to "first item in collection" in many places,
so obviously there is some sort of order. But then, what point is to have
collection instead of array?

I didn't quite follow that sentence, but you can certainly use value
types in hashtables, as either keys or values. They just end up getting
boxed.

I mean, most of the time I don't need "object" key type, it's sort of
overkill. In fact, most of the time I just need string type key and object
type value. A good candidate for this seems to be StringDictionary, and I
hope that using it could have slight effect on code efficiency.


Regards,

Pavils

 

[Jay B. Harlow [MVP - Outlook]]

Pavils,
In addition to Jon's comments.

My understanding of term "collection" comes from VB, especially programming
with classic ASP prior to transerring all ASP developement to JScript

couple
A VB6/ASP Collection is not a .NET collection.

Within .NET you can use Microsoft.VisualBasic.Collection to have the same
functionality as a VB6 Collection.

Rather then using Microsoft.VisualBasic.Collection I use either ArrayList &
a HashTable, or create type safe versions by inheriting from CollectionBase
or DictionaryBase.

Hope this helps
Jay

 

[Bjorn Abelli]

...

Soo.. is there a "place" of item within
collection, or it's like a sack with stuff
where order of thnks is irrelevant?

That is depending on which implementation of ICollection you're using.
ICollection is just an interface, that doesn't care about the order of
items.

I see references to "first item in collection" in many
places, so obviously there is some sort of order. But
then, what point is to have
collection instead of array?

Well, an array *is* actually an implementation of ICollection...

The advantage to use some other class than ordinary arrays for collections
is that the size can be altered "dynamically" by just adding new items.

As *all* types in .NET really are of type object through inheritance, you
can use instances of anything for the key and value respectively.

I mean, most of the time I don't need "object" key
type, it's sort of overkill. In fact, most of the
time I just need string type key and object
type value.

A string is an object.

A good candidate for this seems to be
StringDictionary, and I hope that using it
could have slight effect on code efficiency.

A StringDictionary "implements a hashtable with the key strongly typed to be
a string rather than an object." [From the documentation].

// Bjorn A

 

[Pavils Jurjans]

Hello Bjorn

The advantage to use some other class than ordinary arrays for collections
is that the size can be altered "dynamically" by just adding new items.

I was thinking of ArrayList there

A StringDictionary "implements a hashtable with the key strongly typed to be
a string rather than an object." [From the documentation].

Yes, I actually tested today and found out that StringDictionary actually
enforces *both* key and value to be of string type. That makes me wonder why
then there is the NameValueCollection, which is also a collection of string
key-value pairs. It escapes me why should I use speciffically the one or the
other.

-- Pavils

 

[Bjorn Abelli]

...

I was thinking of ArrayList there

Well, both ArrayList as well as ordinary arrays implements the interface
ICollection.

*Which* implementation to choose is in many cases a choice of preference.

That makes me wonder why then there is the
NameValueCollection, which is also a collection
of string key-value pairs. It escapes me why should
I use speciffically the one or the other.

A NameValueCollection works in a slightly different manner, as it's foremost
a "sorted collection", which means that you can refer to a single item both
through the key as well as using an index.

// Bjorn A

 

[Jay B. Harlow [MVP - Outlook]]

Bjorn,

a "sorted collection", which means that you can refer to a single item both
through the key as well as using an index.

However its not "sorted". ;-)

I had to try it this morning, although the help says its a "sorted
collection" I find it behaves more like an "ordered collection".

The difference being I would expect a "sorted collection" to be always
sorted by the key, while an "ordered collection" is simply ordered by the
order I add key/value pairs to the collection.

Just a thought
Jay

 

[Bjorn Abelli]

Jay B. Harlow wrote...

[On the topic of "NameValueCollection"]

However its not "sorted". ;-)

Well, don't blame me, blame the authors
of Microsoft's help... ;-)


Another odd thing is the results from:

foreach (string y in x)
{
Console.WriteLine(y);
}

....compared to:

for (int i = 0; i < x.Count; i++)
{
Console.WriteLine( x );
}

....when x is a NameValueCollection.

The first one prints the *keys* while the second one prints the *values*.
It's the correct behaviour according the help, but it's not very
intuitive...


// Bjorn A

 

[Jay B. Harlow [MVP - Outlook]]

Bjorn,

Another odd thing is the results from:
foreach (string y in x)
for (int i = 0; i < x.Count; i++)
...when x is a NameValueCollection.
The first one prints the *keys* while the second one prints the *values*.

I hadn't noticed that feature, as in my test I used the key for the value...
In my test I was a little surprised that the For Each returned a string
instead of a DictionaryEntry.

Jay

Jay B. Harlow wrote...

[On the topic of "NameValueCollection"]

However its not "sorted". ;-)

Well, don't blame me, blame the authors
of Microsoft's help... ;-)


Another odd thing is the results from:

foreach (string y in x)
{
Console.WriteLine(y);
}

...compared to:

for (int i = 0; i < x.Count; i++)
{
Console.WriteLine( x );
}

...when x is a NameValueCollection.

The first one prints the *keys* while the second one prints the *values*.
It's the correct behaviour according the help, but it's not very
intuitive...


// Bjorn A

 

[Pavils Jurjans]

Hello John,

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

I am confused about this denial... Say, NameValueCollection 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 NameValueCollection:

foreach (string y in x)
{
Console.WriteLine(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 NameValueCollection enumerator here?

Confused,

Pavils

 

[Jon Skeet [C# MVP]]

I am confused about this denial... Say, NameValueCollection 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 NameValueCollection:

foreach (string y in x)
{
Console.WriteLine(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 NameValueCollection enumerator here?

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

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