Public Class GeoffAppleby

The Problem with Conforming to Standards

...is that it's so much harder.

I was trying to make something 'nice' today, but most of the time had the .net framework slapping me in the face. Maybe it was menstruating, I don't know, but it was sure in a bad mood with me.

I was continuing along with the plans I'd made as I described in my last post here. I did end up going with a base class emulating a lot of the features of ArrayList, without all the bells and whistles.

The real trick with it was to make sure that i didn't serialize a load of gumpf. You see, because I'm dynamically expanding the array as required, and I don't want to do it on every insert, then it doubles it's size every time it gets full. So there's the potential that the internal array contains null entries. I don't really want to serialize these out, so I added an Items property to the base class, with a BrowsableAttribute set on it to false, to try and give later developers an idea that they shouldn't be touching it themselves (without good reason).

This worked, except for the fact that the point to all this was to write strong-typed wrappers - the base class obviously needs to return an object array.  So the derived class shadows the property, casting the object array to a strong typed array (actually, it seems you can't cast an object array to any other type, even if it's really an array some other type, so i had to copy it into a new strong typed array).

All is working nice now. I updated all the code to use this new object instead of the existing one, and all is nice - except for where I loop through each item in the array. Looping through the internal array is no good, because there's potential nulls. Looping through the result of the Items property is no good, because of performance. To begin with i redid all the loops to increment an integer from 0 to Count-1, and grab each item out based on the index. This worked, but I wanted something more. I wanted...For Each! :)

So today I implemented the IEnumerable interface on my base class. All of a sudden, I have an enumerable object, and it's all sweet.

No it's not.

The XMLSerializer, when it sees an object that implements IEnumerable, demands a method on that object Add() which takes a parameter of type object. Well, this screws me up royally, because the whole point to what I'm writing is to make the damn thing strongly typed, and never an Object in sight!

According to one piece of documentation (the previous link to XMLSerializer):

A class that implements IEnumerable must implement a public Add method that takes a single parameter. The Add method's parameter must be of the same type as is returned from the Current property on the value returned from GetEnumerator, or one of that type's bases.

I tested this by shadowing the Current property with one that returned the correct type, but the XMLSerializer still complained. So I gave up on heading down that path.

So I was already to remove IEnumerable again, since it wasn't really necessary for my object to work. But before I did, I tried something out. I stopped implementing the IEnumerable interface, but I left the GetEnumerator method there that the interface requires.

End result? It serializes again, and For Each works! I put some thought into this and realised that the For Each statement in VB is late bound, no matter what your 'Option Strict' settings say (which should always stay ON, right? :) All it cares is that it can find a GetEnumerator method.

So I thought I'd come across a nice balance of good, right, and clean. It wasn't perfect, it's not completely right, but it's right enough for my liking. I still need to test it out and see what the foreach statement in C# does, however the doco looks promising:

Evaluates to a type that implements IEnumerable or a type that declares a GetEnumerator method. In the latter case, GetEnumerator should either return a type that implements IEnumerator or declares all the methods defined in IEnumerator.

So it's most likely that it'll work :)

Are all my troubles over? You'd think so right?

Think again.

I've got a class now that is basically an ArrayList that when implemented is serializable, enumerable (albeit by cheating a little), dynamically expanding, and strongly typed. Lovely. So on one (just one, dammit) of the pages in the web site for this application, it gets data-bound to a repeater control. And does it work? Hell no! The DataSource property of the repeater requires an object the implements either IEnumerable or IListSource. IListSource requires a method that returns something that implements IList, which itself derives from IEnumerable and ICollection.

Luckily, the aforementioned Items property returns a normal ordinary Array - which just so happens to be properly Enumerable. That'll do me fine.

So I think my issues are all sorted, but I spent most of my day ramming my head into a brick wall. Life as a developer is fun, huh? (Yes, I actually do think it is :)