WaiterOperation<T> class

An immutable, value-shaped descriptor of a deferred operation managed by Waiter.

Why a value object? The historic API of Waiter.add(() => ...) stored bare closures directly. Closures cannot be safely sent across Isolate boundaries (the Dart runtime rejects them at SendPort.send time), and they're opaque to logging/audit code — there's nothing to attach an ID or origin to. Wrapping each operation in a value object fixes both issues:

  1. Sendability. If run is a top-level or static function, the entire WaiterOperation graph is SendPort.send-compatible. The type system can't enforce "top-level" — that's a runtime check by the isolate machinery — but the wrapping class gives callers a single place to apply the discipline.
  2. Auditability. id survives the function call; cleanup, cancellation, and structured logging code can refer to operations by name instead of Function identity.

Equality / hashing is intentionally identity-based. Two operations with the same id but different run callbacks are not equal; that matches the existing behaviour of Waiter.remove(operation) which relied on Object.== of the underlying function.

Constructors

WaiterOperation(FutureOr<T> run(), {String? id})
const

Properties

hashCode → int
The hash code for this object.
no setterinherited
id → String?
Optional, caller-supplied identifier. Used purely for logging and auditing; the Waiter never inspects it.
final
run → FutureOr<T> Function()
The function to invoke when the operation is run.
final
runtimeType → Type
A representation of the runtime type of the object.
no setterinherited

Methods

noSuchMethod(Invocation invocation) → dynamic
Invoked when a nonexistent method or property is accessed.
inherited
toString() → String
A string representation of this object.
override

Operators

operator ==(Object other) → bool
The equality operator.
inherited