40722 - Redesign collection classes

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect, P3)

Description

[Warren Harris]

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; ?)

Comment 1

[Warren Harris]

See ancient related bug 7795 on nsIEnumerator.

Comment 2

[Scott Collins]

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.