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

[Jon Skeet [C# MVP]]

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

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.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"?

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.

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

[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?

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"?

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 StringDictionar y, 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.Visua lBasic.Collecti on to have the same
functionality as a VB6 Collection.

Rather then using Microsoft.Visua lBasic.Collecti on I use either ArrayList &
a HashTable, or create type safe versions by inheriting from CollectionBase
or DictionaryBase.

Hope this helps
Jay

"Pavils Jurjans" <pa****@mailbox .riga.lv> wrote in message
news:uf******** ******@TK2MSFTN GP10.phx.gbl... 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?

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"?

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 StringDictionar y, and I
hope that using it could have slight effect on code efficiency.
Regards,

Pavils

[Bjorn Abelli]

"Pavils Jurjans" wrote...

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 "dynamicall y" by just adding new items.

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"?

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
StringDictionar y, and I hope that using it
could have slight effect on code efficiency.

A StringDictionar y "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 "dynamicall y" by just adding new items.
I was thinking of ArrayList there

A StringDictionar y "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 StringDictionar y actually
enforces *both* key and value to be of string type. That makes me wonder why
then there is the NameValueCollec tion, 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]

"Pavils Jurjans" wrote...

The advantage to use some other class than ordinary
arrays for collections is that the size can be altered
"dynamicall y" by just adding new items.
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
NameValueCollec tion, which is also a collection
of string key-value pairs. It escapes me why should
I use speciffically the one or the other.

A NameValueCollec tion 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" <bj**********@D oNotSpam.hotmai l.com> wrote in message
news:eN******** ******@TK2MSFTN GP12.phx.gbl...
"Pavils Jurjans" wrote...

The advantage to use some other class than ordinary
arrays for collections is that the size can be altered
"dynamicall y" by just adding new items.
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
NameValueCollec tion, which is also a collection
of string key-value pairs. It escapes me why should
I use speciffically the one or the other.

A NameValueCollec tion 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

[Bjorn Abelli]

Jay B. Harlow wrote...

[On the topic of "NameValueColle ction"]

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". ;-)

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.WriteLi ne(y);
}

....compared to:

for (int i = 0; i < x.Count; i++)
{
Console.WriteLi ne( x[i] );
}

....when x is a NameValueCollec tion.

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 NameValueCollec tion.
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

"Bjorn Abelli" <bj**********@D oNotSpam.hotmai l.com> wrote in message
news:u6******** ******@TK2MSFTN GP12.phx.gbl... Jay B. Harlow wrote...

[On the topic of "NameValueColle ction"]

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". ;-)

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.WriteLi ne(y);
}

...compared to:

for (int i = 0; i < x.Count; i++)
{
Console.WriteLi ne( x[i] );
}

...when x is a NameValueCollec tion.

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