On 13-02-01 10:36 AM, Chris Peterson wrote:
> strcat and I have been casually brainstorming about container traits.
> Has there been previous discussion about standardizing a container trait
> hierarchy and method naming convention?
Not much; what we've had was encoded mostly in the core::iter and
core::container libraries.
> Below is a rough sketch of a simple container framework, inspired by
> Scala, Python, and C++ STL. Scala has a well-organized trait hierarchy,
> but I'm partial to C++ STL's method names because they are short and
> consistent. :)
>
> * trait Container
> * trait Iterable?
> * trait Map
> * struct LinearMap (and any future hash-based maps)
> * trait OrderedMap? (range queries, forward/reverse iteration)
> * struct TreeMap
> * struct TrieMap?
> * trait Set
> * struct LinearSet (and any future hash-based sets)
> * struct BitSet (includes bit op methods like flip() and to_uint())
> * trait OrderedSet?
> * struct TreeSet
> * struct TrieSet?
> * trait Seq (Sequence)
> * struct Stack
> * trait Queue
> * trait List (or trait Deque?)
> * struct Deque? (vec-based. Vec? VecDeque? "ArrayDeque"
> like Java?)
> * struct LinkedList
> * struct PriorityQueue
Very happy to have people looking at organizing this stuff! It's been
disorganized for a while. A few bits of preference:
- I think Queue and Stack are both traits, extensions of Seq.
- I think the double-ended circular vec struct (implemented unsafely)
should probably be called Buf. It's the replacement for DVec.
Alternatively call it Queue and come up with another name for the
"can access at either end" trait. "Deque" is enough of a C++-ism
that I'm ok leaving it behind.
- I think of List and DoubleList as concrete types, not traits.
- I am still against calling HashMap "LinearMap". It's too specific;
like requiring "LLRBTree" or "AATree" when over "TreeMap". It's fine
to have these as submodules implementing the same outer interface
but to most users, "HashMap" is as specific as they'll want to get.
- I'd prefer List as a concrete type implementing Seq
- Need to differentiate owned types from persistent / managed types;
many or most of these types need both forms.
Thanks for taking an interest!
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
