Collections
Collections in the IOTA framework offer versatile ways to manage groups of data, each tailored to different use cases.
This document serves as an overview, you can learn more about Dynamic Fields and Tables and Bags in the Objects section.
Bag
The Bag module functions as a versatile, map-like collection.
Unlike conventional maps, the Bag does not store its keys and values directly.
Instead, it leverages IOTA's object system to manage storage,
with the Bag struct serving as a handle for retrieving these elements.
It's important to note that Bag instances with identical key-value pairs may not be considered equal
(==) during runtime.
Object Bag
ObjectBag builds on the Bag concept but requires that all associated values be objects. This ensures that these
objects remain accessible in storage, which might be necessary for interaction with external tools. As with Bag, this
difference is not evident within Move itself.
Dynamic Field
IOTA objects can extend beyond their predefined fields by
incorporating iota::dynamic_fields post-construction.
Unlike static field names, dynamic fields can be any value with copy, drop, and store abilities
(e.g., integers, booleans, strings).
This flexibility enables on-the-fly enhancements to objects,
serving as a fundamental component for various collection types.
Dynamic Object Field
The iota::dynamic_object_field module is similar
to iota::dynamic_field,
with the distinction that the values associated with these dynamic fields must themselves be objects.
This design ensures that these objects remain in storage, which is crucial for compatibility with external tools.
Internally, this difference is not noticeable in Move.
Table
The Table module operates as a map-like collection but with a twist.
Instead of directly storing keys and values,
the Table relies on IOTA's object system for storage.
The Table struct itself acts merely as a handle to access these elements.
This means that two Table instances with identical key-value pairs might not be considered equal (==) at runtime.
Linked Table
LinkedTable extends the functionality of the Table module by linking values together, allowing for ordered insertion
and removal.
This feature is particularly useful for scenarios where the order of elements is important.
Table Vec
TableVec is a scalable vector library implemented using the Table module, providing a flexible way to manage
sequential data.
Object Table
ObjectTable<K, V> is akin to the Table module, but with a requirement that all associated values are objects. This
design choice ensures that these objects persist in storage, which may be essential for certain external tools. Within
Move, this difference remains unnoticeable.
Priority Queue
The PriorityQueue module is implemented using a max heap,
providing an efficient way to manage prioritized elements.
Vec Map
The VecMap module provides a map-like structure backed by a vector.
While it guarantees no duplicate keys, entries are stored in insertion order rather than being sorted by key.
Operations on this structure are O(N) relative to the map's size.
This design is intended for scenarios where convenience is more critical than performance. For large maps or
sorted iteration, alternative structures are recommended.
Vec Set
VecSet is a set-like data structure backed by a vector,
ensuring no duplicate keys.
All operations are O(N) in relation to the set's size.
Like VecMap, this structure is designed for convenience, not performance.
For sorted iteration or large sets, consider using custom structures.