Currently we use NamedGraphs.OrderedDictionaries.OrderedIndices as the storage format for NamedGraph vertices. The idea is that it is a Dictionaries.AbstractIndices subtype, so it acts like a set where the indices and values are the members of the set. The OrderedIndices type adds on a separate interface layer where you can index into the OrderedIndices by integer position using NamedGraphs.OrdinalIndexing, so it acts both like a set and like an array.
I've found that this design works pretty well, but I think it causes some awkward situations in generic code that assumes collections are "array-like", i.e. are primarily indexed by integer offsets/positions. Probably we should switch out OrderedIndices for a type that still acts like a set in terms of hashing/fast lookup, but is primarily indexed by integer positions of elements of the set. The closest example I know of in the Julia ecosystem is AcceleratedArrays.jl, we could try that directly or role our own version if it doesn't suit our purposes directly.
Currently we use
NamedGraphs.OrderedDictionaries.OrderedIndicesas the storage format for NamedGraph vertices. The idea is that it is aDictionaries.AbstractIndicessubtype, so it acts like a set where the indices and values are the members of the set. TheOrderedIndicestype adds on a separate interface layer where you can index into theOrderedIndicesby integer position usingNamedGraphs.OrdinalIndexing, so it acts both like a set and like an array.I've found that this design works pretty well, but I think it causes some awkward situations in generic code that assumes collections are "array-like", i.e. are primarily indexed by integer offsets/positions. Probably we should switch out
OrderedIndicesfor a type that still acts like a set in terms of hashing/fast lookup, but is primarily indexed by integer positions of elements of the set. The closest example I know of in the Julia ecosystem is AcceleratedArrays.jl, we could try that directly or role our own version if it doesn't suit our purposes directly.