You didn't answer the casting question from post #2.
I picked list because it would have been the most likely thing people would have run into. So your shop never had to deal with domain specific objects and those objects needed to be kept in some kind of data structure beyond an array? Did your shop just have to deal with DataTable
and DataSet
and arrays only?
Did you just use WinForms controls to act as data structures and just cast objects when getting thing out of them? (e.g. Use a TreeView
to hold tree like structures; use a ListBox
to hold lists of items.)
How did your shop deal with mapping one type to another type? Hard coded switch
statements and casting types with the .NET Framework 1.1 Dictionary
?
If you were dealing with WinForms, did you ever had to implement a custom control with custom events? Did those events ever have to derive from the basic EventArgs
? Since you say you never had to use generics, that would then mean that you had to explicitly declare event handler delegates for each of those custom events instead of just using EventHandler<T>
.
Perhaps it may help if you tell us a bit about the problem space that you and your team used to tackle. Perhaps it may explain why you didn't really run into them or see a need for generics.
For example, my father used to use computers a lot and did some custom programming, but all he really needed was matrices of floating point numbers. Just implement variable sized matrices with matrix operations for floating point numbers and he was happy. Any support methods for scanning through the matrices to select particular rows, columns just devolved into returning an 1xN or Nx1 matrix. For his needs, he didn't really need any generics.