FYI, I'm in the process of converting fun_treemap into an AA Tree and
implement much of the container traits. In the process, I've extracted out
the mutation functions from Map and Set into their own "Mutable{Map,Set}"
trait, and added "Immutable{Map,Set}" traits for persistent types. So
please talk to me before any of you start handling the mutable/persistent
type issue.On Fri, Feb 1, 2013 at 11:24 AM, Graydon Hoare <[email protected]> wrote: > 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 >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
