Time is not on my side
I was redesigning some of my collection classes today. As always happens with iterative development, the vision we had of what was required when we started this project is slightly different to the end result. An outcome of this is that while all our business classes work, and quite well, there's some internal implementation issues that could be refined.
An example of this is our List object. In the first iteration, it was a class that inherited from IDictionary, making a nice, speedy, strongly typed hashtable. Many of our web methods return objects of this type. Then in the interests of making things a bit better, I stopped deriving from IDictionary, but instead used an internal hashtable as a private member. The difference was subtle, but better.
It ends up now that we don't actually need any hashtable specific accessors, so indexed lookups are not important. An array is all we need. Sometimes the simplest things are the best, after all. :)
This object does need to be serialized through the web service however, so I want to keep the classes as neat an friendly as possible, with regards to serialization. For storing all the items inside this class I see two main options: using an array from the outset, or some sort of dynamically growing thing like ArrayList.
ArrayList is nice in that I just keep adding things to the list, and it internally (and I presume in some sort of optimised manner) grows it's internal array as required. But it implements all manner of interfaces, including IList, ICollection, and a few others. From now on I really want to try to avoid serializing collections or dictionaries, so I'd like to avoid it. An plain old array is cleaner and lighter, and all i need for the sake of serialization, but I'll have to maintain growth of the array myself, in possibly not as optimised a manner as the ArrayList or other provided BCL objects are.
On top of this, I've got a reuse problem. Over the course of this application, I need to use about 5 different versions for storing different data types in its internal array/list. If write a base class that wraps all the list type stuff, I will have to declare everything as Object. If write a custom class for each type so that it can be strongly typed, then I have a maintenance issue. Yes, I could write a strong typed wrapper around a object-based list, but I still having boxing issues when its used.
I haven't decided what I'm actually going to do yet - I think I'll use a base class plus strongly typed wrapper approach for now, but we all know what I really need, right?
Generics.
Which leads me to my point (finally, I know!). I've noticed something in myself as far as new features are concerned in VS2005. When I first heard about some of the features of Whidbey, it was at Teched in 2003. I was impressed, and looking forward to it, but I knew it was a long way off. It didn't effect me right now. I was more impressed by the sneak preview they gave of Yukon.
Over the last 6 months or more, however, the phrase 'well, we can do that in whidbey' comes out of my mouth more and more often. Which led me to write a formula:
Where t is the time until
Whidbey is released, and I is my impatience level.
Yes, my maths knowledge is astounding. Basically, as Whidbey gets closer, I'm getting more and more impatient.
God dammit guys, hurry up already! I need it now! :)
Listening to: brush away - alice in chains - (3:22)