There... I've said it. We need to completely redesign our collection class hierarchy before we can export it as an officially supported interface of xpcom. Here's what I would like to see: 1. Make a sane interface hierarchy that reflects operation semantics consistently for each interface. What do I mean by this? Something like this: nsICollection - has membership operations (include/exclude/has), no notion of ordering nsIOrderedCollection - includes notion of ordering, enumeration nsIIndexedCollection - has access by index ...something like that (I haven't thought too deeply on this yet). I do have a great paper on this sort of thing though that we could use for insight. (Cook analyzing the Smalltalk collection hierarchy in OOPSLA '89?) 2. Similar treatment as for nsString - abstract base classes so that (a) collections can be passed around without regard for their implementation, (b) flexibility to change/improve the implementation in later releases, and (c) ability to provide alternate implementations for different situations (e.g. linked-list-ordered-collection vs. vector-ordered-collection). Implementation classes should allow for stack allocation, at least of the collection header, but it would also be nice to provide stack-allocated elements, e.g. nsAutoVoidArray (might allow first N elements on the stack), or even nsLiteralVoidArray which allows all entries to be specified at construction time. 3. Templates for collection classes. I think having templates to access collection elements will both facilitate understanding our code, and eliminate a slew of unnecessary QueryInterface calls (for the case where some place in the code puts an nsIFoo into the collection, and some other body of code pulls an nsIFoo out of the collection -- we only need to QI when someone tries to pull out a subclass of nsIFoo). Note that we need to figure out how to relate any templates we invent here to IDL and JS. (Can we just forward reference nsIFooArray in IDL and then in C++ typedef nsArray<nsIFoo> nsIFooArray; ?)

See ancient related bug 7795 on nsIEnumerator.

I guess we missed the boat on these (by about a hemisphere). Our collection classes are pretty much frozen across the board; I don't see any realistic mass resolution to this situation before 2.0.