support any indexable collection in `Indices`?

[simeonschaub]

I would like to enforce a particular partial order upon dict construction and for that I'd like to have an AbstractIndices object backed by any collection that supports a notion of indexing (e.g. getindex, setindex!, firstindex, nextind and lastindex) instead of being limited to Vectors like Indices. My first thought was to just make the types of hashes and values in Indices parametric. Looking at the implementation, I believe one difficulty would be that there needs to be some way of figuring out a sentinel value to denote an empty slot in slots, but perhaps that can just default to something like firstindex(x) - 1 and be overloadable in any cases where that doesn't work? Another problem would probably the use of resize! since that assumes new items always get inserted at the end, which wouldn't hold true in the case I'm thinking of. Another option might be to separate all the hashtable code from the rest of the Indices impkementation, so it's easy to reuse in custom subtypes of AbstractIndices. Any thoughts? Is this something you thought about before?

[andyferris]

Yeah, parts of it could definitely be refactored to be more reusable.

Adding parameters to Dictionary has the unfortunate problem of making the "simple" case more complex. Perhaps it is worth it; I don't know.

When I had my first attempt at writing this package Dictionary was a type that had a kind of index -> token container inside and another token -> value container inside (both going via getindex but not having to be AbstractDictionarys themselves). You basically didn't need any other kind of dictionary; you just stuck different stuff inside it. It found it got a bit confusing to do the generic thing, so I backed out and did some more specialised implementations. However it was my first attempt and it might be possible to do neatly.