The Gold Standard of Websites | Tracing Set.intersection Order When the Smaller Operand Changes

A mathematical intersection answers which values are common. A JavaScript Set also exposes insertion order when it is iterated, so an accurate explanation must answer both questions. Start by naming the object, operation and observation separately. That small discipline prevents a convenient surface description from replacing the mechanism that actually decides the result.

Worked case. Let the receiver be new Set(["B", "A", "C"]) and the other operand be new Set(["C", "B"]). The common values are B and C, but the initial result iterates as C then B because the smaller operand supplies the traversal order. Write the observations in order and keep values, calls and returned containers distinct. The point of the example is not merely to obtain an answer; it is to make every decisive step inspectable.

A useful trace records what is read first, which callable is invoked, what state is consulted, and whether the visible outcome is available now or later. If one of those facts is missing, two programs that look similar can be reported as though they had the same behaviour.

Changed-context check. Add X and Y only to the other operand. The mathematical intersection is still B and C, yet the receiver is now smaller and the result iterates as B then C. Re-run the trace from the changed premise instead of editing the old conclusion. This is how the explanation transfers to unfamiliar code without turning one remembered example into a universal rule.

Limit and evidence check. Do not sort either result during diagnosis, because sorting would erase the very observation this lesson is designed to explain. Prefer a finite fixture, an event ledger and an exact assertion. The check should distinguish the competing explanations rather than merely confirming the final printed value.

For a practical review, ask three questions: what did the caller request, what did the language operation actually do, and what may the host or surrounding code still change? Answering all three keeps the report useful to a learner and honest about its boundary.

Now test the tempting shortcut against this chapter’s case. A shortcut that predicts only the final value misses the decisive observation in: A mathematical intersection answers which values are common. A JavaScript Set also exposes insertion order when it is iterated, so an accurate explanation must answer both questions. State what that shortcut would get wrong, then point to the one ledger entry or identity assertion that corrects it. This converts a rule into a reusable diagnostic rather than another phrase to memorise.

Contents · Next chapter

The receiver must be an actual Set object with the required internal storage. The other argument can be a set-like object, but its size, has and keys properties are obtained through a separate protocol. Start by naming the object, operation and observation separately. That small discipline prevents a convenient surface description from replacing the mechanism that actually decides the result.

Worked case. Call receiver.intersection(other) with a genuine receiver and a plain set-like object that logs its size, has and keys property reads. The ledger reveals preparation before the size branch. Write the observations in order and keep values, calls and returned containers distinct. The point of the example is not merely to obtain an answer; it is to make every decisive step inspectable.

A useful trace records what is read first, which callable is invoked, what state is consulted, and whether the visible outcome is available now or later. If one of those facts is missing, two programs that look similar can be reported as though they had the same behaviour.

Changed-context check. Borrow the method with .call({ }, other) and observe the early TypeError before the other object can rescue the missing Set internal slot. Re-run the trace from the changed premise instead of editing the old conclusion. This is how the explanation transfers to unfamiliar code without turning one remembered example into a universal rule.

Limit and evidence check. A lookalike object with values and a has method is not automatically a valid receiver. Prefer a finite fixture, an event ledger and an exact assertion. The check should distinguish the competing explanations rather than merely confirming the final printed value.

For a practical review, ask three questions: what did the caller request, what did the language operation actually do, and what may the host or surrounding code still change? Answering all three keeps the report useful to a learner and honest about its boundary.

Now test the tempting shortcut against this chapter’s case. A shortcut that predicts only the final value misses the decisive observation in: The receiver must be an actual Set object with the required internal storage. The other argument can be a set-like object, but its size, has and keys properties are obtained through a separate protocol. State what that shortcut would get wrong, then point to the one ledger entry or identity assertion that corrects it. This converts a rule into a reusable diagnostic rather than another phrase to memorise.

Contents · Previous chapter · Next chapter

The branch condition compares the receiver’s live Set data size with the set-like size converted to a number. Equal sizes take the receiver-traversal branch. Start by naming the object, operation and observation separately. That small discipline prevents a convenient surface description from replacing the mechanism that actually decides the result.

Worked case. Use receiver order B,A,C and other order C,B,X. With equal size three, the receiver is traversed and membership is asked through the other operand’s has method, yielding B,C. Write the observations in order and keep values, calls and returned containers distinct. The point of the example is not merely to obtain an answer; it is to make every decisive step inspectable.

A useful trace records what is read first, which callable is invoked, what state is consulted, and whether the visible outcome is available now or later. If one of those facts is missing, two programs that look similar can be reported as though they had the same behaviour.

Changed-context check. Delete X before the call so the other size becomes two. The branch changes and its keys iterator supplies C,B. Re-run the trace from the changed premise instead of editing the old conclusion. This is how the explanation transfers to unfamiliar code without turning one remembered example into a universal rule.

Limit and evidence check. The comparison is an algorithmic choice for work and order; it is not a claim that one set is more important. Prefer a finite fixture, an event ledger and an exact assertion. The check should distinguish the competing explanations rather than merely confirming the final printed value.

For a practical review, ask three questions: what did the caller request, what did the language operation actually do, and what may the host or surrounding code still change? Answering all three keeps the report useful to a learner and honest about its boundary.

Now test the tempting shortcut against this chapter’s case. A shortcut that predicts only the final value misses the decisive observation in: The branch condition compares the receiver’s live Set data size with the set-like size converted to a number. Equal sizes take the receiver-traversal branch. State what that shortcut would get wrong, then point to the one ledger entry or identity assertion that corrects it. This converts a rule into a reusable diagnostic rather than another phrase to memorise.

Contents · Previous chapter · Next chapter

When receiver size is less than or equal to the reported other size, the algorithm walks receiver Set data and calls the captured other has function for each live value. Start by naming the object, operation and observation separately. That small discipline prevents a convenient surface description from replacing the mechanism that actually decides the result.

Worked case. For receiver B,A,C and other C,B,X,Y, has is queried in B,A,C order. Only B and C are appended, preserving their receiver encounter order. Write the observations in order and keep values, calls and returned containers distinct. The point of the example is not merely to obtain an answer; it is to make every decisive step inspectable.

A useful trace records what is read first, which callable is invoked, what state is consulted, and whether the visible outcome is available now or later. If one of those facts is missing, two programs that look similar can be reported as though they had the same behaviour.

Changed-context check. Reinsert B at the end of the receiver before calling. The common members stay the same, while receiver traversal now encounters A,C,B and produces C,B. Re-run the trace from the changed premise instead of editing the old conclusion. This is how the explanation transfers to unfamiliar code without turning one remembered example into a universal rule.

Limit and evidence check. Mutations triggered by the other has function can affect a live traversal; isolate such effects when teaching the baseline. Prefer a finite fixture, an event ledger and an exact assertion. The check should distinguish the competing explanations rather than merely confirming the final printed value.

For a practical review, ask three questions: what did the caller request, what did the language operation actually do, and what may the host or surrounding code still change? Answering all three keeps the report useful to a learner and honest about its boundary.

Now test the tempting shortcut against this chapter’s case. A shortcut that predicts only the final value misses the decisive observation in: When receiver size is less than or equal to the reported other size, the algorithm walks receiver Set data and calls the captured other has function for each live value. State what that shortcut would get wrong, then point to the one ledger entry or identity assertion that corrects it. This converts a rule into a reusable diagnostic rather than another phrase to memorise.

Contents · Previous chapter · Next chapter

When the receiver is larger, the algorithm obtains an iterator from the captured keys method and tests each yielded key against the receiver’s own Set data. Start by naming the object, operation and observation separately. That small discipline prevents a convenient surface description from replacing the mechanism that actually decides the result.

Worked case. For receiver B,A,C and other keys C,B, the iterator yields C then B and both are appended in that order. The receiver’s insertion order does not reorder them afterward. Write the observations in order and keep values, calls and returned containers distinct. The point of the example is not merely to obtain an answer; it is to make every decisive step inspectable.

A useful trace records what is read first, which callable is invoked, what state is consulted, and whether the visible outcome is available now or later. If one of those facts is missing, two programs that look similar can be reported as though they had the same behaviour.

Changed-context check. Reverse the other set insertion order to B,C without changing membership or size. The result order becomes B,C. Re-run the trace from the changed premise instead of editing the old conclusion. This is how the explanation transfers to unfamiliar code without turning one remembered example into a universal rule.

Limit and evidence check. A set-like keys method must return an iterator object. Returning an array without first obtaining its iterator is a protocol error. Prefer a finite fixture, an event ledger and an exact assertion. The check should distinguish the competing explanations rather than merely confirming the final printed value.

For a practical review, ask three questions: what did the caller request, what did the language operation actually do, and what may the host or surrounding code still change? Answering all three keeps the report useful to a learner and honest about its boundary.

Now test the tempting shortcut against this chapter’s case. A shortcut that predicts only the final value misses the decisive observation in: When the receiver is larger, the algorithm obtains an iterator from the captured keys method and tests each yielded key against the receiver’s own Set data. State what that shortcut would get wrong, then point to the one ledger entry or identity assertion that corrects it. This converts a rule into a reusable diagnostic rather than another phrase to memorise.

Contents · Previous chapter · Next chapter

Adding values that are not in the intersection can still change the size comparison. That can switch the source traversal even though no new common member is added. Start by naming the object, operation and observation separately. That small discipline prevents a convenient surface description from replacing the mechanism that actually decides the result.

Worked case. Start with other C,B, then add X and Y. Neither new value belongs to the receiver, but size changes from two to four and the result order flips from C,B to B,C. Write the observations in order and keep values, calls and returned containers distinct. The point of the example is not merely to obtain an answer; it is to make every decisive step inspectable.

A useful trace records what is read first, which callable is invoked, what state is consulted, and whether the visible outcome is available now or later. If one of those facts is missing, two programs that look similar can be reported as though they had the same behaviour.

Changed-context check. Instead add unrelated values to the receiver. The branch may remain on other keys, showing that the location of the size change matters. Re-run the trace from the changed premise instead of editing the old conclusion. This is how the explanation transfers to unfamiliar code without turning one remembered example into a universal rule.

Limit and evidence check. Do not describe the flip as random or engine-specific when the size branch and insertion orders fully account for it. Prefer a finite fixture, an event ledger and an exact assertion. The check should distinguish the competing explanations rather than merely confirming the final printed value.

For a practical review, ask three questions: what did the caller request, what did the language operation actually do, and what may the host or surrounding code still change? Answering all three keeps the report useful to a learner and honest about its boundary.

Now test the tempting shortcut against this chapter’s case. A shortcut that predicts only the final value misses the decisive observation in: Adding values that are not in the intersection can still change the size comparison. That can switch the source traversal even though no new common member is added. State what that shortcut would get wrong, then point to the one ledger entry or identity assertion that corrects it. This converts a rule into a reusable diagnostic rather than another phrase to memorise.

Contents · Previous chapter · Next chapter

Set membership uses keyed-collection equality. NaN can match NaN, and negative zero is canonicalized so a result does not preserve a distinct negative-zero identity. Start by naming the object, operation and observation separately. That small discipline prevents a convenient surface description from replacing the mechanism that actually decides the result.

Worked case. Intersect new Set([NaN, -0]) with new Set([0, NaN]) and inspect membership plus Object.is on the yielded zero. Write the observations in order and keep values, calls and returned containers distinct. The point of the example is not merely to obtain an answer; it is to make every decisive step inspectable.

A useful trace records what is read first, which callable is invoked, what state is consulted, and whether the visible outcome is available now or later. If one of those facts is missing, two programs that look similar can be reported as though they had the same behaviour.

Changed-context check. Replace NaN with two separate but equal-looking objects. They do not intersect unless both operands contain the same object reference. Re-run the trace from the changed premise instead of editing the old conclusion. This is how the explanation transfers to unfamiliar code without turning one remembered example into a universal rule.

Limit and evidence check. Avoid JSON stringification as an equality test because it changes NaN and erases object identity. Prefer a finite fixture, an event ledger and an exact assertion. The check should distinguish the competing explanations rather than merely confirming the final printed value.

For a practical review, ask three questions: what did the caller request, what did the language operation actually do, and what may the host or surrounding code still change? Answering all three keeps the report useful to a learner and honest about its boundary.

Now test the tempting shortcut against this chapter’s case. A shortcut that predicts only the final value misses the decisive observation in: Set membership uses keyed-collection equality. NaN can match NaN, and negative zero is canonicalized so a result does not preserve a distinct negative-zero identity. State what that shortcut would get wrong, then point to the one ledger entry or identity assertion that corrects it. This converts a rule into a reusable diagnostic rather than another phrase to memorise.

Contents · Previous chapter · Next chapter

The other operand is prepared as a record containing a non-negative size, a has callable and a keys callable. Those properties can be getters and can log or fail. Start by naming the object, operation and observation separately. That small discipline prevents a convenient surface description from replacing the mechanism that actually decides the result.

Worked case. Give size a getter returning 2, has a function, and keys a generator. Record which call path is used after the size comparison. Write the observations in order and keep values, calls and returned containers distinct. The point of the example is not merely to obtain an answer; it is to make every decisive step inspectable.

A useful trace records what is read first, which callable is invoked, what state is consulted, and whether the visible outcome is available now or later. If one of those facts is missing, two programs that look similar can be reported as though they had the same behaviour.

Changed-context check. Raise the reported size to 20 without changing keys. The branch switches to receiver traversal and keys may never be called. Re-run the trace from the changed premise instead of editing the old conclusion. This is how the explanation transfers to unfamiliar code without turning one remembered example into a universal rule.

Limit and evidence check. A dishonest size can change work and output order; it does not grant the object genuine Set internal storage. Prefer a finite fixture, an event ledger and an exact assertion. The check should distinguish the competing explanations rather than merely confirming the final printed value.

For a practical review, ask three questions: what did the caller request, what did the language operation actually do, and what may the host or surrounding code still change? Answering all three keeps the report useful to a learner and honest about its boundary.

Now test the tempting shortcut against this chapter’s case. A shortcut that predicts only the final value misses the decisive observation in: The other operand is prepared as a record containing a non-negative size, a has callable and a keys callable. Those properties can be getters and can log or fail. State what that shortcut would get wrong, then point to the one ledger entry or identity assertion that corrects it. This converts a rule into a reusable diagnostic rather than another phrase to memorise.

Contents · Previous chapter · Next chapter

Protocol methods are obtained during set-record preparation. Later mutation of the property does not necessarily replace the callable already captured for this operation. Start by naming the object, operation and observation separately. That small discipline prevents a convenient surface description from replacing the mechanism that actually decides the result.

Worked case. Use getters that return labelled functions, then change the public has property from inside another effect. The current trace should still identify the captured function. Write the observations in order and keep values, calls and returned containers distinct. The point of the example is not merely to obtain an answer; it is to make every decisive step inspectable.

A useful trace records what is read first, which callable is invoked, what state is consulted, and whether the visible outcome is available now or later. If one of those facts is missing, two programs that look similar can be reported as though they had the same behaviour.

Changed-context check. Run a second intersection after the mutation. The second call performs fresh property reads and may capture the replacement. Re-run the trace from the changed premise instead of editing the old conclusion. This is how the explanation transfers to unfamiliar code without turning one remembered example into a universal rule.

Limit and evidence check. Do not infer method-capture timing from the final result alone; log the getter and callable identities. Prefer a finite fixture, an event ledger and an exact assertion. The check should distinguish the competing explanations rather than merely confirming the final printed value.

For a practical review, ask three questions: what did the caller request, what did the language operation actually do, and what may the host or surrounding code still change? Answering all three keeps the report useful to a learner and honest about its boundary.

Now test the tempting shortcut against this chapter’s case. A shortcut that predicts only the final value misses the decisive observation in: Protocol methods are obtained during set-record preparation. Later mutation of the property does not necessarily replace the callable already captured for this operation. State what that shortcut would get wrong, then point to the one ledger entry or identity assertion that corrects it. This converts a rule into a reusable diagnostic rather than another phrase to memorise.

Contents · Previous chapter · Next chapter

The other-keys branch consumes an iterator. If a relevant abrupt completion occurs, iterator closing rules determine whether its return method is called. Start by naming the object, operation and observation separately. That small discipline prevents a convenient surface description from replacing the mechanism that actually decides the result.

Worked case. Use a keys generator with a finally marker and a yielded value that causes a protocol failure during processing. Confirm the marker before reporting resource cleanup. Write the observations in order and keep values, calls and returned containers distinct. The point of the example is not merely to obtain an answer; it is to make every decisive step inspectable.

A useful trace records what is read first, which callable is invoked, what state is consulted, and whether the visible outcome is available now or later. If one of those facts is missing, two programs that look similar can be reported as though they had the same behaviour.

Changed-context check. Change the example so iteration ends normally. The finally marker still appears, but the completion path is different and must be labelled correctly. Re-run the trace from the changed premise instead of editing the old conclusion. This is how the explanation transfers to unfamiliar code without turning one remembered example into a universal rule.

Limit and evidence check. A finalization marker proves control reached cleanup code; it does not by itself prove which earlier operation failed. Prefer a finite fixture, an event ledger and an exact assertion. The check should distinguish the competing explanations rather than merely confirming the final printed value.

For a practical review, ask three questions: what did the caller request, what did the language operation actually do, and what may the host or surrounding code still change? Answering all three keeps the report useful to a learner and honest about its boundary.

Now test the tempting shortcut against this chapter’s case. A shortcut that predicts only the final value misses the decisive observation in: The other-keys branch consumes an iterator. If a relevant abrupt completion occurs, iterator closing rules determine whether its return method is called. State what that shortcut would get wrong, then point to the one ledger entry or identity assertion that corrects it. This converts a rule into a reusable diagnostic rather than another phrase to memorise.

Contents · Previous chapter · Next chapter

The specification accounts for live collection data and notes cases where calls can remove and re-add values. Such effects may revisit a value or alter later observations. Start by naming the object, operation and observation separately. That small discipline prevents a convenient surface description from replacing the mechanism that actually decides the result.

Worked case. Let the other has callback delete and re-add a receiver member during receiver traversal, and record the exact query sequence with a strict finite guard. Write the observations in order and keep values, calls and returned containers distinct. The point of the example is not merely to obtain an answer; it is to make every decisive step inspectable.

A useful trace records what is read first, which callable is invoked, what state is consulted, and whether the visible outcome is available now or later. If one of those facts is missing, two programs that look similar can be reported as though they had the same behaviour.

Changed-context check. Repeat with a pure has function. The simple trace should contain one query per original receiver value and becomes the preferred teaching baseline. Re-run the trace from the changed premise instead of editing the old conclusion. This is how the explanation transfers to unfamiliar code without turning one remembered example into a universal rule.

Limit and evidence check. Never use an unbounded mutation experiment; a callback that keeps extending a live collection can make a demonstration fail to finish. Prefer a finite fixture, an event ledger and an exact assertion. The check should distinguish the competing explanations rather than merely confirming the final printed value.

For a practical review, ask three questions: what did the caller request, what did the language operation actually do, and what may the host or surrounding code still change? Answering all three keeps the report useful to a learner and honest about its boundary.

Now test the tempting shortcut against this chapter’s case. A shortcut that predicts only the final value misses the decisive observation in: The specification accounts for live collection data and notes cases where calls can remove and re-add values. Such effects may revisit a value or alter later observations. State what that shortcut would get wrong, then point to the one ledger entry or identity assertion that corrects it. This converts a rule into a reusable diagnostic rather than another phrase to memorise.

Contents · Previous chapter · Next chapter

If downstream code needs a canonical order, intersection iteration order should not be treated as a hidden sorting service. Apply an explicit ordering rule after computing membership. Start by naming the object, operation and observation separately. That small discipline prevents a convenient surface description from replacing the mechanism that actually decides the result.

Worked case. For tags with a priority list, compute the intersection and then sort by the priority index. The business order is now documented independently of operand sizes. Write the observations in order and keep values, calls and returned containers distinct. The point of the example is not merely to obtain an answer; it is to make every decisive step inspectable.

A useful trace records what is read first, which callable is invoked, what state is consulted, and whether the visible outcome is available now or later. If one of those facts is missing, two programs that look similar can be reported as though they had the same behaviour.

Changed-context check. If encounter order is meaningful, keep the operand and insertion-order contract visible instead of sorting. Re-run the trace from the changed premise instead of editing the old conclusion. This is how the explanation transfers to unfamiliar code without turning one remembered example into a universal rule.

Limit and evidence check. Explicit sorting has its own comparator, stability and cost considerations; state them rather than calling the order natural. Prefer a finite fixture, an event ledger and an exact assertion. The check should distinguish the competing explanations rather than merely confirming the final printed value.

For a practical review, ask three questions: what did the caller request, what did the language operation actually do, and what may the host or surrounding code still change? Answering all three keeps the report useful to a learner and honest about its boundary.

Now test the tempting shortcut against this chapter’s case. A shortcut that predicts only the final value misses the decisive observation in: If downstream code needs a canonical order, intersection iteration order should not be treated as a hidden sorting service. Apply an explicit ordering rule after computing membership. State what that shortcut would get wrong, then point to the one ledger entry or identity assertion that corrects it. This converts a rule into a reusable diagnostic rather than another phrase to memorise.

Contents · Previous chapter · Next chapter

A strong test checks membership, iteration order and protocol calls separately. One combined deep equality assertion can hide which contract failed. Start by naming the object, operation and observation separately. That small discipline prevents a convenient surface description from replacing the mechanism that actually decides the result.

Worked case. Assert the result values C,B for the smaller-other case, then assert the logged keys pulls and absence of has calls expected for that branch. Write the observations in order and keep values, calls and returned containers distinct. The point of the example is not merely to obtain an answer; it is to make every decisive step inspectable.

A useful trace records what is read first, which callable is invoked, what state is consulted, and whether the visible outcome is available now or later. If one of those facts is missing, two programs that look similar can be reported as though they had the same behaviour.

Changed-context check. Add two unrelated other values and assert B,C plus receiver-ordered has calls. Re-run the trace from the changed premise instead of editing the old conclusion. This is how the explanation transfers to unfamiliar code without turning one remembered example into a universal rule.

Limit and evidence check. Keep fixtures fresh because previous insertion and deletion history changes Set order even when current membership looks identical. Prefer a finite fixture, an event ledger and an exact assertion. The check should distinguish the competing explanations rather than merely confirming the final printed value.

For a practical review, ask three questions: what did the caller request, what did the language operation actually do, and what may the host or surrounding code still change? Answering all three keeps the report useful to a learner and honest about its boundary.

Now test the tempting shortcut against this chapter’s case. A shortcut that predicts only the final value misses the decisive observation in: A strong test checks membership, iteration order and protocol calls separately. One combined deep equality assertion can hide which contract failed. State what that shortcut would get wrong, then point to the one ledger entry or identity assertion that corrects it. This converts a rule into a reusable diagnostic rather than another phrase to memorise.

Contents · Previous chapter · Next chapter

Suppose a role Set contains write,read,archive while a request Set contains archive,write. The effective permissions are the intersection, but display order follows the active branch. Start by naming the object, operation and observation separately. That small discipline prevents a convenient surface description from replacing the mechanism that actually decides the result.

Worked case. With the request smaller, the result displays archive then write. Add harmless requested flags until the role is smaller and it displays write then archive. Write the observations in order and keep values, calls and returned containers distinct. The point of the example is not merely to obtain an answer; it is to make every decisive step inspectable.

A useful trace records what is read first, which callable is invoked, what state is consulted, and whether the visible outcome is available now or later. If one of those facts is missing, two programs that look similar can be reported as though they had the same behaviour.

Changed-context check. Use a separate UI ordering map if the product requires read,write,archive regardless of calculation history. Re-run the trace from the changed premise instead of editing the old conclusion. This is how the explanation transfers to unfamiliar code without turning one remembered example into a universal rule.

Limit and evidence check. Permissions still require authorization policy; intersection order is a presentation and reasoning issue, not proof that a permission should be granted. Prefer a finite fixture, an event ledger and an exact assertion. The check should distinguish the competing explanations rather than merely confirming the final printed value.

For a practical review, ask three questions: what did the caller request, what did the language operation actually do, and what may the host or surrounding code still change? Answering all three keeps the report useful to a learner and honest about its boundary.

Now test the tempting shortcut against this chapter’s case. A shortcut that predicts only the final value misses the decisive observation in: Suppose a role Set contains write,read,archive while a request Set contains archive,write. The effective permissions are the intersection, but display order follows the active branch. State what that shortcut would get wrong, then point to the one ledger entry or identity assertion that corrects it. This converts a rule into a reusable diagnostic rather than another phrase to memorise.

Contents · Previous chapter · Next chapter

A usable report names receiver order, other order, both sizes and the branch. It then states common membership and result iteration order separately. Start by naming the object, operation and observation separately. That small discipline prevents a convenient surface description from replacing the mechanism that actually decides the result.

Worked case. Report: receiver B,A,C size3; other C,B size2; traverse other keys; membership B,C; iteration C,B. Write the observations in order and keep values, calls and returned containers distinct. The point of the example is not merely to obtain an answer; it is to make every decisive step inspectable.

A useful trace records what is read first, which callable is invoked, what state is consulted, and whether the visible outcome is available now or later. If one of those facts is missing, two programs that look similar can be reported as though they had the same behaviour.

Changed-context check. Changed report: other C,B,X,Y size4; traverse receiver; membership B,C; iteration B,C. Re-run the trace from the changed premise instead of editing the old conclusion. This is how the explanation transfers to unfamiliar code without turning one remembered example into a universal rule.

Limit and evidence check. Do not say JavaScript reordered the answer without identifying the size branch and encounter order that produced it. Prefer a finite fixture, an event ledger and an exact assertion. The check should distinguish the competing explanations rather than merely confirming the final printed value.

For a practical review, ask three questions: what did the caller request, what did the language operation actually do, and what may the host or surrounding code still change? Answering all three keeps the report useful to a learner and honest about its boundary.

Now test the tempting shortcut against this chapter’s case. A shortcut that predicts only the final value misses the decisive observation in: A usable report names receiver order, other order, both sizes and the branch. It then states common membership and result iteration order separately. State what that shortcut would get wrong, then point to the one ledger entry or identity assertion that corrects it. This converts a rule into a reusable diagnostic rather than another phrase to memorise.

Contents · Previous chapter · Return to Websites