Generics vs. System.Object collections

  • Thread starter Thread starter Keith Patrick
  • Start date Start date
K

Keith Patrick

I'm curious as to what the role of the legacy collections in .Net will be
once generics are part of the CLR. I prefer to use strongly-typed
collections everywhere (going so far as creating a whole slew of typed
collections like StringList/StringDictionary, Int32List/Int32Dictionary,
etc...Those classes are wrappers, incidentally, so I can code them now with
less elegant implementations while allowing for easy migration to the
generics versions). But I'm curious if there is a role any more for regular
System.Object collections outside scenarious where someone really would want
to store anything. For example, because all objects have .ToString(), is it
overkill to have StringList? I tend to be a purist in this sense and say
convenience of not having to write a StringList class should take a back
seat to having collections with compile-time type checking, but that's just
me.
 
Keith Patrick said:
I'm curious as to what the role of the legacy collections in .Net will be
once generics are part of the CLR. I prefer to use strongly-typed
collections everywhere (going so far as creating a whole slew of typed
collections like StringList/StringDictionary, Int32List/Int32Dictionary,
etc...Those classes are wrappers, incidentally, so I can code them now with
less elegant implementations while allowing for easy migration to the
generics versions). But I'm curious if there is a role any more for regular
System.Object collections outside scenarious where someone really would want
to store anything. For example, because all objects have .ToString(), is it
overkill to have StringList? I tend to be a purist in this sense and say
convenience of not having to write a StringList class should take a back
seat to having collections with compile-time type checking, but that's just
me.
Click to expand...

It absolutely makes sense to have a StringList:

1) Calling ToString() every time you take something out of the list is
about as expensive as casting, takes just as long to type and clutters
up the code just as much.

2) (More importantly) Making the list only *accept* strings at compile-
time means you're more likely to catch bugs at compile-time rather than
run-time.

Now I personally don't mind keeping things in a straight ArrayList for
the moment, but that doesn't mean there aren't advantages in having
type-specific collections for strings.
 
My thinking is pretty much to have a collection for every value object that
I've got. Now, that adds to my file (and class) count, but I get
compile-time checks for everything (I've never been a big fan of
..ToString(), even in Java, though, as I find it encourages sloppiness and
inconsistency quite a bit. Nice for watching variables in the debugger,
though, but the Whidbey visualization stuff is much nicer). The only thing
is, I would prefer to make the collections public inner classes to the value
objects for organizational purposes, but FxCop doesn't like inner classes
being public, and I want to abide by MS' guidelines (although regardless of
whether or not they say it may be bad to use StringList instead of
List<String>, I'm adhering to the wrapper class so that I can code with
type safety right now, but move over to generics with only a change in
coding at one spot)
 
Back
Top