MOO programming beyond the playground

1. From a player command to a verb call

An explicit call such as box:put(item) supplies values directly. A command such as put brush in box starts as text. The server and core resolve objects and match a verb’s names and argument specifications. The same verb can receive very different context depending on how it was invoked.

• dobjstr is direct-object text; dobj is the resolved object reference. They are not interchangeable.
• iobjstr and iobj describe the indirect object. prepstr records the preposition.
• argstr is the command argument text. Command args are not a programmatic API’s typed argument list.
• Argument specifications describe command matching; they do not validate every explicit call.

Practice on a real server: inspect an existing command’s metadata, write down its receiver and resolved objects, then test a missing object, an ambiguous object name, and the equivalent explicit call. Separate the player-facing command from a reusable verb that accepts already validated values.

2. Decide whose authority matters

The player associated with a task, the immediate caller, the receiver, and the programmer whose permissions apply are different concepts. A single “is player the owner?” check is not a universal authorization policy.

• A command UI may make player-specific decisions. A callable API must also account for calls made by other code.
• A private helper may require a particular caller. A delegated operation may use caller permissions deliberately.
• Property and verb flags control access on a real server; metadata inspection in this playground does not enforce those protections.
• Be cautious about wizard-owned verbs and changing task permissions. Validate authorization before changing persistent state.

Practice: create two ordinary players and a disposable object. Test read, write and explicit-call access from each player and from a nested verb. Explain the expected permission identity before each test. Never use the playground’s successful operation as evidence that a permission boundary is secure.

3. Cooperate with a scheduler

A native MOO can suspend a task and run other tasks before resuming it. Cooperative scheduling is distinct from native multithreading. Between suspension and resumption, another task may move, modify or recycle an object.

"Conceptual real-server pattern; not runnable in this playground.";
target = args[1];
suspend(1);
if (!valid(target))
  return;
endif
"Recheck the relevant state and authorization here before acting.";

Practice: on a disposable real server, arrange for a second task to change a target while the first is suspended. Observe why checking only before suspension is insufficient. Capture necessary values before a fork, revalidate after yields, and consult the core’s task-management conventions. Learn queue inspection and cancellation before implementing repeating jobs.

The playground has execution limits and worker Stop, but no fork, suspend/resume, queued-task scheduler or native threading APIs.

4. Distinguish identity from lifetime

A numbered object reference can outlive the referenced object. Explicit renumbering or recreation can reuse numbers. Anonymous objects and WAIFs introduce additional value and lifetime rules; this runtime does not implement them. A core may also use soft recycling, so its validity helpers can differ from the native valid builtin.

Practice: trace one object from creation through initialization, containment changes and recycling. Identify references left elsewhere in the database. Read your core’s recycler before adding automatic cleanup. Keep class inheritance separate from physical containment.

5. Move an integration into a real environment

The playground’s files, connections and external responses are educational boundaries. A real server adds authentication, server options, network failures, resource quotas, database permissions and operational recovery.

1. Write down the request, response types and expected failure modes.
2. Use prepared fixtures to test data handling without contacting a service.
3. Test the real adapter with limited permissions and disposable data.
4. Test missing input, invalid data, timeouts, retries and duplicate requests.
5. Verify persistence and recovery, then document which server/core version you tested.

SQLite here is real but deliberately restricted. Fixed-zero memory counters, no-op reseeding and simulated shutdown are not native measurements or operational controls. Multiple inheritance, native multithreading and bytecode inspection are deliberately outside this learning runtime.