API conventions

Toolkit-wide naming and API conventions: what names mean, when a property is a getter vs a getXXX() method, and the deliberate, documented exceptions. Similar things are named similarly; a name deviates only when functionality or complexity genuinely differs.

Getters, setters, and methods

Property getters and setters are reserved for O(1), idempotent operations. Getters have no side effects; setters at most trivial ones. Anything with a non-trivial algorithm — or any side effect — is a method, and the getXXX()/setXXX() spelling signals that cost:

Surface	Why it is a method
getLength() on lists	counting a linked list is O(n) — contrast the O(1) size getters elsewhere
getBack() on ExtSList	reaching the last node of a headless SLL is an O(n) walk
setCapacity() on caches	shrinking evicts entries — an algorithm, not an assignment
find()/get() on caches	promotes the entry (LRU order, frequency counters) — the side-effect-free read is peek()
getMin()/getMax() on trees	O(depth) walks, not field reads

Where the same concept is O(1), it is a property: SList.back rides a maintained last pointer, adapter size is tracked, heap top is array[0].

Element counts: size and length

size is the canonical O(1) element count across the toolkit (the Map/Set convention). length exists as an equal alias on the heaps (their historical primary), SkipList, and SplayTree. Linked lists deliberately have neither — their count is O(n), so it is spelled getLength().

push / pop mean different ends in different families

A deliberate exception, driven by complexity and domain convention:

Family	push	pop	Rationale
Raw lists (List, SList, ValueList, ValueSList)	pushFront	popFront	the front is the O(1)-universal end — valid even for SLLs (no O(1) popBack)
Deque family (Deque, RingBuffer, UnrolledList)	pushBack	popBack	Array parity, completed by shift/unshift
Queue	pushBack	popFront	a FIFO pipe: in at the back, out at the front (enqueue/dequeue)
Heaps	insert	extract-min	universal heap vocabulary

When writing generic code, prefer the explicit names (pushFront, popBack, …) — they mean the same thing everywhere they exist.

Lookups

find returns the container's handle type: nodes for SplayTree, SkipList, and lists (the node is the useful handle), values for caches (Map parity, aliased get). has is a boolean membership test everywhere. peek is always a side-effect-free read.

On self-adjusting structures the read/write split is explicit: SplayTree.find() is read-only; promote() is the splaying access (see SplayTree).

Constructors and building

• Constructors take an options object ({less, compare, ...}); caches also accept a bare capacity number (new CacheLRU(100) ≡ new CacheLRU({capacity: 100})).
• The list adapters (Queue, Stack, Deque) accept an underlying list instance (adopted) or a list class (instantiated).
• Every container buildable from values has a static from(values, ...).

Ordering functions

Ordered containers and heaps take less(a, b) (prototype a < b) or compare(a, b) (prototype a - b; overrides less when set) — see each class's options.

Aliases

Aliases are zero-cost prototype references (addAlias/addAliases from meta-utils), not wrappers. Established families: Array parity on deques (push/pop/shift/unshift), Map parity on caches (get/set/delete), domain vocabulary on adapters (enqueue/dequeue), and add/remove as each adapter's natural in/out verbs.