Crates.io | flow_arena |
lib.rs | flow_arena |
version | 0.4.4 |
source | src |
created_at | 2021-04-22 20:04:15.774826 |
updated_at | 2021-04-30 05:42:06.653961 |
description | A HashMap managed Graph Model with the concept of ownership |
homepage | |
repository | https://github.com/LighghtEeloo/flow.er |
max_upload_size | |
id | 388284 |
size | 57,854 |
A HashMap
managed graph model with the concept of ownership.
The flow_arena
package consists of
trait Flow
and struct FlowArena
trait Node
and struct FlowNode
GraphNode
and GraphArena
.FlowArena
grants you the ability to:
In fact, it all started with Rust's ownership rules...
When it comes to relation driven data models, it's easy to make Rustaceans headache - just try and write a safe doubly-linked list. The concept of Arena
, therefore, is raised to implement a simple and memory-safe representation of such models. 1
Consider a tree model. Basically it's a group of nodes where each node can point to some other nodes. How do we denote this relation? Well, we give every node a unique mark which claims its reference. We used to use pointers to cleverly mark this uniqueness with the help of memory addresses; but due to Rust's ownership rule, this approach is verbose to implement. So, why not mark this uniqueness by ourselves, with indices or ids?
The idea of the Arena
is simple: use a Vec<Node>
or a HashMap<Id, Node<Id>>
to contain all the nodes, where each node contains a collection of indices / ids, e.g. Vec<Id>
, as well as its own data. We can mark a node with its index / id, thus we can designate a root node; to traverse, just recursively get a node and traverse its "node marker collection".
FlowArena
represents a directed graph with the idea of Arena
. More than that, it's also able to represent the "flow model".
Flow model is different from graph or tree model alone because it provides both ownership (tree-ish) and linkage (graph-ish) features. Suppose you are removing a node from a tree, the children of it will automatically be removed, which is an implication of the "ownership" of a node to its children. In contrast, a graph node's removal will not cause the surrounding nodes to be removed.
Using the concept of ownership in the current graph-ish model, we yield a new kind of data model that can freely switch its behaviour between the two modes. We call such a data model a "flow model", which clearly indicates the functionality of FlowArena
.
Important: there are some extra concepts in FlowArena
compared to Arena
:
nodes have not only children(Vec<Id>
), but also a optional parent (Option<Id>
)
None
means root; and children is only extra notation for possible ownershipany node can have its sub tree or sub graph, given that no external linkage exist
the nodes with no parent are called orphan
s which is similar to a group of "root" nodes.
struct FlowNode<Id>
and the struct FlowArena<Id, Entity>
to represent a flow modeltrait Node<Id>
and trait Flow
- see Trait Implementation for referenceuse
the corresponding traitFlowBase
: provides basic node-reflection abiliy; no check
FlowCheck
: checks the Flow's properties and see whether they hold
FlowMap
: provides hashmap functionality
FlowLink
: provides ability to link nodes; graph-ish
FlowDevote
: provides ability to devote / own nodes; tree-ish
FlowDock
: provides ability to cut (undock) and copy (snap) a flow from a node and paste it to another node (dock)
FlowShift
: provides ability to move around in flow with Direction
Flow
: checks all the traits are implemented
The FlowArena
is serving as the underlying data model of flow.er, a notebook, mindmap, todo-list and agenda app.