Skip to main content

Ordered

Trait Ordered 

Source
pub trait Ordered {
    // Required method
    fn order_key(&self) -> OrderKey<'_>;
}
Expand description

What a collection’s items answer so that the collection can be put in canonical order.

Implemented on the domain type, once, next to the type — not on a view of it beside a renderer. Every projection then sorts by calling canonical, and none of them holds an opinion of its own about the sequence.

Required Methods§

Source

fn order_key(&self) -> OrderKey<'_>

The four parts this item is ordered by. Borrowed from the item: building a key allocates nothing, so sorting a large collection costs the comparisons and no more.

Dyn Compatibility§

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementations on Foreign Types§

Source§

impl Ordered for (String, EconomicsRun)

A run record, with the path it was read from, orders by the run’s id; two records of one id — the duplicate the loader reports — by their paths, so the order is total and the record reported is the later one on every machine.

Source§

fn order_key(&self) -> OrderKey<'_>

Source§

impl Ordered for String

A bare string is ordered by itself.

A list of paths, ids or names is a collection like any other, and it had no way to reach the canonical order without a comparator written beside it. This is that way: one implementation, so canonical orders a Vec<String> the same way it orders everything else — naturally, and identically on every machine, which sort() does not promise because it compares bytes and natural_cmp compares what a person reads.

use majordomus_cli::order::canonical;

let mut paths = vec!["a/item-10".to_string(), "a/item-2".to_string()];
canonical(&mut paths);
assert_eq!(paths, ["a/item-2", "a/item-10"]);
Source§

fn order_key(&self) -> OrderKey<'_>

Source§

impl<T: Ordered + ?Sized> Ordered for &T

A reference orders as the item it points at, so a projection can put a borrowed view of a collection in canonical order without cloning every item into a vector first.

Source§

fn order_key(&self) -> OrderKey<'_>

Implementors§

Source§

impl Ordered for Area

Source§

impl Ordered for Audience

Source§

impl Ordered for BranchState

A branch state is the branch it describes, ordered by the same name, so the topology listing and the trace listing read in the same sequence.

Source§

impl Ordered for Capability

A capability is presented by its id: the command line’s table, the site’s registry pages and the closure matrix all list it that way, and a title is neither unique nor stable enough to be the thing a reader navigates by.

Source§

impl Ordered for CapabilityView

The view orders as the capability it carries: the source path it adds is provenance.

Source§

impl Ordered for CommitReference

The commit is what a reader looks for; the entry that named it ends the key, because one commit is named by several records and each of those is a separate fact.

Source§

impl Ordered for Conflict

Filed under the kind of disagreement, then the current entry, and ended by the entry it stands against — the pair is what makes one conflict distinct from another under a kind.

Source§

impl Ordered for DeclaredEvent

Source§

impl Ordered for Deduplicated

Filed under what made the two the same thing, then by the entry that survived — which is unique, because one entry is kept once under one key.

Source§

impl Ordered for Deployment

A deployment is presented by its id, which is its identity within the repository; the title is prose and two deployments may well be given the same one.

Source§

impl Ordered for DeploymentView

The view orders as the deployment it wraps: the file path it adds is provenance, not a second opinion about the sequence.

Source§

impl Ordered for Domain

A domain is presented by its weight, then its id: the order the homepage map, the domain index and every listing of domains share.

Source§

impl Ordered for DroppedFile

A dropped file is listed by its path; the path is unique in the index, so it is both the label and the identity.

Source§

impl Ordered for EconomicsContextRun

A context measurement orders by when it was taken, then by the commit it measured, never by its file name, so the last one is the latest. measured_at is a UTC RFC 3339 timestamp at whole seconds, whose digit runs have fixed widths, so the natural order reads it chronologically.

Source§

impl Ordered for EconomicsHistoryPoint

A point of the history orders within its suite by when it was measured, then by the revision it was measured at. at is a UTC RFC 3339 timestamp at whole seconds, whose digit runs have fixed widths, so the natural order reads it chronologically.

Source§

impl Ordered for EconomicsModelTotal

A model’s totals order by the model’s name, which the provider reports once per run.

Source§

impl Ordered for EconomicsRunView

A run in brief orders by its id, and by the path of its record when two share one.

Source§

impl Ordered for Edge

An edge is ordered by the relation it is, then by which way it runs, then by what a reader sees.

The relation is the group, because that is the bucket the reader is actually scanning — every depends_on together, every put_in_force together — and the direction is a rank inside it rather than the most significant part, because every consumer of this collection filters to one direction before it renders (the entity page draws the declared references and the backlinks as two sections). The URI is the tie-breaker, and an external end that has none falls back to its label; edges dedups, so two edges that compare equal here were the same edge twice.

This is the whole order of the collection. There was a sort_by here beside the building of it, which is the second opinion crate::order exists to remove — the natural comparison it brings is also the one every other surface of this repository shows, so case-2 precedes case-10 on an entity page as it does everywhere else.

Source§

impl Ordered for Episode

Source§

impl Ordered for EvidenceRunRecord

A recording is ordered by when it was recorded, and its id — unique, the run_id — makes the order total when two were recorded in the same second. RFC 3339 UTC reads in time order under the canonical comparison, its digit runs being fixed-width.

Source§

impl Ordered for Excluded

The tier is the precedence the budget spends in, so it is the explicit rank; inside a tier a reader looks for a reason, and the identifier ends the key so the list is total.

Source§

impl Ordered for Execution

A ledger holds one execution per test, so the test identifies it; the label and the identity are the same string because there is nothing else to read it by.

Source§

impl Ordered for Feature

Source§

impl Ordered for Gate

Source§

impl Ordered for Holding

One collection, one order, declared once: at-risk holdings first (the group), then by kind in the order a worker meets them (a work tree, its branch, a stash), then by identity. Every surface that lists holdings shows this order, because none of them sorts.

Source§

impl Ordered for IntentWorkRef

The work realising an intent reads strongest link first, then by the record it came from, then by its identity.

Source§

impl Ordered for IssuePurpose

Issues are listed in the natural order of their identity, as everywhere else.

Source§

impl Ordered for KindCount

Source§

impl Ordered for KindView

A kind is presented by its name, which is the identity the whole index files objects under; there is nothing else about a kind that a reader would look it up by.

Source§

impl Ordered for KnowledgeCandidate

The queue orders by id, which the deriver makes total: the episode, then a digest of the evidence.

Source§

impl Ordered for McpClient

A client is the provider it belongs to, and is ordered by that id: the order every other listing of providers reads in, whatever order the distribution declared them in.

Source§

impl Ordered for ModuleView

A module is presented by its id, the same string its capabilities are prefixed with.

Source§

impl Ordered for Moment

Source§

impl Ordered for Orphan

A path names one file, so it is both what a reader looks for and the identity that makes the orphan list total.

Source§

impl Ordered for PathChange

A plan’s changes in canonical order: by path, then by the status git reported, so the halves of one path stay adjacent and dedup_by sees them together.

Source§

impl Ordered for PlanIssue

An issue is shown, everywhere, in the natural order of its identity: issue-2 before issue-10, which is the order its file names read in.

Source§

impl Ordered for ProductProvider

A provider is presented by its id — the directory its bootstrap is written under and the name every other projection of the product matrix refers to it by.

Source§

impl Ordered for ProviderStatus

A provider id is unique in a mesh, so it is both what a reader looks for and the identity that makes the status list total.

Source§

impl Ordered for ReasoningRecord

Records are in the order they were written: by their millisecond stamp, then by id. The stamps are fixed-width, so the label orders as time does.

Source§

impl Ordered for RecordedSpelling

Source§

impl Ordered for Row

A matrix row is the capability it reports on, and is ordered by the same id the registry and the site order capabilities by, so the three can be read side by side.

Source§

impl Ordered for RuleDefinition

A rule is ordered by its namespace, then by what a reader reads, then by its id — so that the vendored package and the project’s own rules stay in their blocks and the sequence is total whatever order discovery handed them.

Source§

impl Ordered for RuleProof

A proof is ordered by the rule it is about: one comparator, so a filtered report and the whole report cannot disagree about the sequence.

Source§

impl Ordered for ScopeUse

A scope is shown most-used first; between equally used scopes, by name.

Source§

impl Ordered for Sighting

A node is sighted at most once per source — a second sighting from the same source replaces the first — so the source is the whole key, and it is the explicit rank because its order is the declared precedence of the transports, not the alphabet of their names. The path and the timestamp end the key so that it stays total if that ever stops being true.

Source§

impl Ordered for Stray

Strays are shown in path order, which is the only order that is a property of the store rather than of the walk that found it: read_dir yields what the filesystem feels like yielding, and two runs over one store must answer identically.

Source§

impl Ordered for Surface

A surface is presented by its id: the composition writes its artifact under that name, the topology reports it under that name, and the title is prose.

Source§

impl Ordered for UncommittedWorktree

Abandoned work first, then recent, then held; inside each, the oldest first; the path breaks a tie, so two readings of one disk list it in one order.

Source§

impl Ordered for WorkflowDescriptor