When a learner can reproduce a familiar example but a small variation causes confusion, the problem is usually an incomplete model rather than a lack of effort. The fastest useful response is to expose the hidden state and test one boundary at a time.
JavaScript WeakMap associates values with weakly held object keys, and the collection deliberately offers no enumeration or size because observing key disappearance would expose garbage-collection timing. Mastery means choosing identity-based object keys, understanding which references remain strong, using get, set, has and delete precisely, and selecting WeakMap only when entries should not keep otherwise unreachable keys alive. This guide begins with that mechanism, then develops it through worked traces, deliberate mistakes, explained practice and transfer decisions.
The aim is independent reasoning. A learner should be able to predict behaviour, locate the earliest wrong assumption, use a safe diagnostic procedure and defend a design choice in a new project.
Punggol families can use the guide in short sessions around homework, CCAs and rest. The activities are proposed learning exercises, not claims about a physical branch, timetable, class size, fee, school relationship or guaranteed result.
Use disposable data and repositories, preserve backups, and check version-sensitive details against the official source. Current documentation settles a technical contract; observation and explanation turn that contract into usable knowledge.
Find your next learning step
Choose the route that matches the present difficulty. Use the complete index for a systematic course.
Build the model
Chapters 1-4 . Begin here, then continue after the learner can predict, verify and explain.
Use the core tools
Chapters 5-8 . Begin here, then continue after the learner can predict, verify and explain.
Handle boundaries
Chapters 9-12 . Begin here, then continue after the learner can predict, verify and explain.
Debug and verify
Chapters 13-16 . Begin here, then continue after the learner can predict, verify and explain.
Transfer with judgment
Chapters 17-20 . Begin here, then continue after the learner can predict, verify and explain.
Open the full chapter index . Jump to capstone practice . Use the How Studying Works hub . Read the official documentation
Complete chapter index
Chapters 1-4 . Build the model
Chapters 5-8 . Use the core tools
Chapters 9-12 . Handle boundaries
Chapters 13-16 . Debug and verify
Chapters 17-20 . Transfer with judgment
A WeakMap holds its keys weakly but retains each associated value as long as the key remains reachable and the entry exists. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is calling the whole entry weak and assuming values can disappear while a live key remains. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Draw external references to key and value separately, then remove only one reference at a time.
For the Weak keys and strong values chapter on JavaScript WeakMap, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on calling the whole entry weak and assuming values can disappear while a live key remains. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const wm=new WeakMap();
const key={id:1};
wm.set(key,{note:'ready'});Explained result. The object key can participate without the WeakMap alone keeping it alive; get(key) returns the strongly associated value while key is reachable. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: homework cards. Predict the rule using object-keyed feedback metadata outside the visible task object. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A WeakMap holds its keys weakly but retains each associated value as long as the key remains reachable and the entry exists.” Apply this procedure: Draw external references to key and value separately, then remove only one reference at a time. The expected mechanism is: The object key can participate without the WeakMap alone keeping it alive; get(key) returns the strongly associated value while key is reachable. For the homework cards, add one near-miss that exposes calling the whole entry weak and assuming values can disappear while a live key remains. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: library records. Contrast the rule using temporary processing state attached to book objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A WeakMap holds its keys weakly but retains each associated value as long as the key remains reachable and the entry exists.” Apply this procedure: Draw external references to key and value separately, then remove only one reference at a time. The expected mechanism is: The object key can participate without the WeakMap alone keeping it alive; get(key) returns the strongly associated value while key is reachable. For the library records, add one near-miss that exposes calling the whole entry weak and assuming values can disappear while a live key remains. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA interface. Stress-test the rule using DOM element state removed when elements become unreachable. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A WeakMap holds its keys weakly but retains each associated value as long as the key remains reachable and the entry exists.” Apply this procedure: Draw external references to key and value separately, then remove only one reference at a time. The expected mechanism is: The object key can participate without the WeakMap alone keeping it alive; get(key) returns the strongly associated value while key is reachable. For the CCA interface, add one near-miss that exposes calling the whole entry weak and assuming values can disappear while a live key remains. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: science model. Explain the rule using cached derived readings keyed by immutable experiment objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A WeakMap holds its keys weakly but retains each associated value as long as the key remains reachable and the entry exists.” Apply this procedure: Draw external references to key and value separately, then remove only one reference at a time. The expected mechanism is: The object key can participate without the WeakMap alone keeping it alive; get(key) returns the strongly associated value while key is reachable. For the science model, add one near-miss that exposes calling the whole entry weak and assuming values can disappear while a live key remains. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers calling the whole entry weak and assuming values can disappear while a live key remains.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Draw external references to key and value separately, then remove only one reference at a time.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript WeakMap syntax. For this chapter, useful prompts are: “What did you expect from Weak keys and strong values?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing calling the whole entry weak and assuming values can disappear while a live key remains be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny budget dashboard with formatting metadata keyed by row objects. Include one ordinary case, one boundary and one deliberate failure caused by calling the whole entry weak and assuming values can disappear while a live key remains. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A WeakMap holds its keys weakly but retains each associated value as long as the key remains reachable and the entry exists. It shows a trace, not only a final value. The ordinary case should demonstrate “The object key can participate without the WeakMap alone keeping it alive; get(key) returns the strongly associated value while key is reachable.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Draw external references to key and value separately, then remove only one reference at a time. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Weak keys and strong values, separate the documented JavaScript WeakMap mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
WeakMap keys must be objects or non-registered symbols under the current ECMAScript contract; ordinary primitives and registered symbols are rejected. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is using a string ID because Map accepted it. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Validate key type at the boundary and use Map when primitive keys are part of the model.
For the Valid keys follow the current language contract chapter on JavaScript WeakMap, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using a string ID because Map accepted it. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const wm=new WeakMap();
wm.set({},'ok');Explained result. An object is a valid identity key; wm.set(‘id’,’x’) throws TypeError. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA interface. Contrast the rule using DOM element state removed when elements become unreachable. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap keys must be objects or non-registered symbols under the current ECMAScript contract; ordinary primitives and registered symbols are rejected.” Apply this procedure: Validate key type at the boundary and use Map when primitive keys are part of the model. The expected mechanism is: An object is a valid identity key; wm.set(‘id’,’x’) throws TypeError. For the CCA interface, add one near-miss that exposes using a string ID because Map accepted it. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: science model. Stress-test the rule using cached derived readings keyed by immutable experiment objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap keys must be objects or non-registered symbols under the current ECMAScript contract; ordinary primitives and registered symbols are rejected.” Apply this procedure: Validate key type at the boundary and use Map when primitive keys are part of the model. The expected mechanism is: An object is a valid identity key; wm.set(‘id’,’x’) throws TypeError. For the science model, add one near-miss that exposes using a string ID because Map accepted it. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision app. Explain the rule using private per-instance state maintained by a module. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap keys must be objects or non-registered symbols under the current ECMAScript contract; ordinary primitives and registered symbols are rejected.” Apply this procedure: Validate key type at the boundary and use Map when primitive keys are part of the model. The expected mechanism is: An object is a valid identity key; wm.set(‘id’,’x’) throws TypeError. For the revision app, add one near-miss that exposes using a string ID because Map accepted it. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: budget dashboard. Transfer the rule using formatting metadata keyed by row objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap keys must be objects or non-registered symbols under the current ECMAScript contract; ordinary primitives and registered symbols are rejected.” Apply this procedure: Validate key type at the boundary and use Map when primitive keys are part of the model. The expected mechanism is: An object is a valid identity key; wm.set(‘id’,’x’) throws TypeError. For the budget dashboard, add one near-miss that exposes using a string ID because Map accepted it. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers using a string ID because Map accepted it.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Validate key type at the boundary and use Map when primitive keys are part of the model.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript WeakMap syntax. For this chapter, useful prompts are: “What did you expect from Valid keys follow the current language contract?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using a string ID because Map accepted it be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny transport map with marker information associated with element objects. Include one ordinary case, one boundary and one deliberate failure caused by using a string ID because Map accepted it. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: WeakMap keys must be objects or non-registered symbols under the current ECMAScript contract; ordinary primitives and registered symbols are rejected. It shows a trace, not only a final value. The ordinary case should demonstrate “An object is a valid identity key; wm.set(‘id’,’x’) throws TypeError.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Validate key type at the boundary and use Map when primitive keys are part of the model. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Valid keys follow the current language contract, separate the documented JavaScript WeakMap mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Two objects with identical properties are different keys unless they are the same reference. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is reconstructing an equal-looking object for lookup. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Keep the original object reference or use a stable primitive key in Map.
For the Object identity decides matches chapter on JavaScript WeakMap, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on reconstructing an equal-looking object for lookup. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const a={id:1},b={id:1};
const wm=new WeakMap([[a,'A']]);
[wm.get(a),wm.get(b)]Explained result. The result is A and undefined because b is not the same object as a. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision app. Stress-test the rule using private per-instance state maintained by a module. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Two objects with identical properties are different keys unless they are the same reference.” Apply this procedure: Keep the original object reference or use a stable primitive key in Map. The expected mechanism is: The result is A and undefined because b is not the same object as a. For the revision app, add one near-miss that exposes reconstructing an equal-looking object for lookup. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: budget dashboard. Explain the rule using formatting metadata keyed by row objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Two objects with identical properties are different keys unless they are the same reference.” Apply this procedure: Keep the original object reference or use a stable primitive key in Map. The expected mechanism is: The result is A and undefined because b is not the same object as a. For the budget dashboard, add one near-miss that exposes reconstructing an equal-looking object for lookup. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: transport map. Transfer the rule using marker information associated with element objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Two objects with identical properties are different keys unless they are the same reference.” Apply this procedure: Keep the original object reference or use a stable primitive key in Map. The expected mechanism is: The result is A and undefined because b is not the same object as a. For the transport map, add one near-miss that exposes reconstructing an equal-looking object for lookup. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: debug lab. Predict the rule using two equal-looking but distinct object identities. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Two objects with identical properties are different keys unless they are the same reference.” Apply this procedure: Keep the original object reference or use a stable primitive key in Map. The expected mechanism is: The result is A and undefined because b is not the same object as a. For the debug lab, add one near-miss that exposes reconstructing an equal-looking object for lookup. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers reconstructing an equal-looking object for lookup.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Keep the original object reference or use a stable primitive key in Map.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript WeakMap syntax. For this chapter, useful prompts are: “What did you expect from Object identity decides matches?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing reconstructing an equal-looking object for lookup be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny debug lab with two equal-looking but distinct object identities. Include one ordinary case, one boundary and one deliberate failure caused by reconstructing an equal-looking object for lookup. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Two objects with identical properties are different keys unless they are the same reference. It shows a trace, not only a final value. The ordinary case should demonstrate “The result is A and undefined because b is not the same object as a.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Keep the original object reference or use a stable primitive key in Map. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Object identity decides matches, separate the documented JavaScript WeakMap mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
set associates a value with a valid key and returns the WeakMap, enabling deliberate chaining. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is reading the return value as the inserted value. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Inspect identity of the returned collection and retrieve the value separately.
For the set returns the WeakMap chapter on JavaScript WeakMap, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on reading the return value as the inserted value. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const wm=new WeakMap();
const k={};
const returned=wm.set(k,42);Explained result. returned === wm, while wm.get(k) is 42. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: transport map. Explain the rule using marker information associated with element objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “set associates a value with a valid key and returns the WeakMap, enabling deliberate chaining.” Apply this procedure: Inspect identity of the returned collection and retrieve the value separately. The expected mechanism is: returned === wm, while wm.get(k) is 42. For the transport map, add one near-miss that exposes reading the return value as the inserted value. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: debug lab. Transfer the rule using two equal-looking but distinct object identities. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “set associates a value with a valid key and returns the WeakMap, enabling deliberate chaining.” Apply this procedure: Inspect identity of the returned collection and retrieve the value separately. The expected mechanism is: returned === wm, while wm.get(k) is 42. For the debug lab, add one near-miss that exposes reading the return value as the inserted value. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: homework cards. Predict the rule using object-keyed feedback metadata outside the visible task object. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “set associates a value with a valid key and returns the WeakMap, enabling deliberate chaining.” Apply this procedure: Inspect identity of the returned collection and retrieve the value separately. The expected mechanism is: returned === wm, while wm.get(k) is 42. For the homework cards, add one near-miss that exposes reading the return value as the inserted value. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: library records. Contrast the rule using temporary processing state attached to book objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “set associates a value with a valid key and returns the WeakMap, enabling deliberate chaining.” Apply this procedure: Inspect identity of the returned collection and retrieve the value separately. The expected mechanism is: returned === wm, while wm.get(k) is 42. For the library records, add one near-miss that exposes reading the return value as the inserted value. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers reading the return value as the inserted value.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Inspect identity of the returned collection and retrieve the value separately.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript WeakMap syntax. For this chapter, useful prompts are: “What did you expect from set returns the WeakMap?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing reading the return value as the inserted value be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny homework cards with object-keyed feedback metadata outside the visible task object. Include one ordinary case, one boundary and one deliberate failure caused by reading the return value as the inserted value. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: set associates a value with a valid key and returns the WeakMap, enabling deliberate chaining. It shows a trace, not only a final value. The ordinary case should demonstrate “returned === wm, while wm.get(k) is 42.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Inspect identity of the returned collection and retrieve the value separately. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For set returns the WeakMap, separate the documented JavaScript WeakMap mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
get returns the stored value or undefined, so a stored undefined cannot be distinguished from absence without has. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is using get alone when undefined is a legitimate value. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Call has when presence itself matters.
For the get distinguishes absence only by undefined chapter on JavaScript WeakMap, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using get alone when undefined is a legitimate value. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
wm.set(k,undefined);
[wm.get(k),wm.has(k)]Explained result. The value is undefined while has is true, proving the entry exists. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: homework cards. Transfer the rule using object-keyed feedback metadata outside the visible task object. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “get returns the stored value or undefined, so a stored undefined cannot be distinguished from absence without has.” Apply this procedure: Call has when presence itself matters. The expected mechanism is: The value is undefined while has is true, proving the entry exists. For the homework cards, add one near-miss that exposes using get alone when undefined is a legitimate value. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: library records. Predict the rule using temporary processing state attached to book objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “get returns the stored value or undefined, so a stored undefined cannot be distinguished from absence without has.” Apply this procedure: Call has when presence itself matters. The expected mechanism is: The value is undefined while has is true, proving the entry exists. For the library records, add one near-miss that exposes using get alone when undefined is a legitimate value. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA interface. Contrast the rule using DOM element state removed when elements become unreachable. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “get returns the stored value or undefined, so a stored undefined cannot be distinguished from absence without has.” Apply this procedure: Call has when presence itself matters. The expected mechanism is: The value is undefined while has is true, proving the entry exists. For the CCA interface, add one near-miss that exposes using get alone when undefined is a legitimate value. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: science model. Stress-test the rule using cached derived readings keyed by immutable experiment objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “get returns the stored value or undefined, so a stored undefined cannot be distinguished from absence without has.” Apply this procedure: Call has when presence itself matters. The expected mechanism is: The value is undefined while has is true, proving the entry exists. For the science model, add one near-miss that exposes using get alone when undefined is a legitimate value. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers using get alone when undefined is a legitimate value.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Call has when presence itself matters.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript WeakMap syntax. For this chapter, useful prompts are: “What did you expect from get distinguishes absence only by undefined?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using get alone when undefined is a legitimate value be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny library records with temporary processing state attached to book objects. Include one ordinary case, one boundary and one deliberate failure caused by using get alone when undefined is a legitimate value. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: get returns the stored value or undefined, so a stored undefined cannot be distinguished from absence without has. It shows a trace, not only a final value. The ordinary case should demonstrate “The value is undefined while has is true, proving the entry exists.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Call has when presence itself matters. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For get distinguishes absence only by undefined, separate the documented JavaScript WeakMap mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
has reports whether an entry exists for the exact key without exposing other keys. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is treating matching properties as membership. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Test the original reference and one structural twin.
For the has tests identity membership chapter on JavaScript WeakMap, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on treating matching properties as membership. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const key={topic:'math'};wm.set(key,true);wm.has(key);Explained result. Membership is true only for that same key identity. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA interface. Predict the rule using DOM element state removed when elements become unreachable. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “has reports whether an entry exists for the exact key without exposing other keys.” Apply this procedure: Test the original reference and one structural twin. The expected mechanism is: Membership is true only for that same key identity. For the CCA interface, add one near-miss that exposes treating matching properties as membership. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: science model. Contrast the rule using cached derived readings keyed by immutable experiment objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “has reports whether an entry exists for the exact key without exposing other keys.” Apply this procedure: Test the original reference and one structural twin. The expected mechanism is: Membership is true only for that same key identity. For the science model, add one near-miss that exposes treating matching properties as membership. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision app. Stress-test the rule using private per-instance state maintained by a module. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “has reports whether an entry exists for the exact key without exposing other keys.” Apply this procedure: Test the original reference and one structural twin. The expected mechanism is: Membership is true only for that same key identity. For the revision app, add one near-miss that exposes treating matching properties as membership. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: budget dashboard. Explain the rule using formatting metadata keyed by row objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “has reports whether an entry exists for the exact key without exposing other keys.” Apply this procedure: Test the original reference and one structural twin. The expected mechanism is: Membership is true only for that same key identity. For the budget dashboard, add one near-miss that exposes treating matching properties as membership. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers treating matching properties as membership.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Test the original reference and one structural twin.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript WeakMap syntax. For this chapter, useful prompts are: “What did you expect from has tests identity membership?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing treating matching properties as membership be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny CCA interface with DOM element state removed when elements become unreachable. Include one ordinary case, one boundary and one deliberate failure caused by treating matching properties as membership. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: has reports whether an entry exists for the exact key without exposing other keys. It shows a trace, not only a final value. The ordinary case should demonstrate “Membership is true only for that same key identity.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Test the original reference and one structural twin. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For has tests identity membership, separate the documented JavaScript WeakMap mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
delete removes the entry for an exact key and returns whether an entry was removed. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is deleting an equal-looking replacement object and expecting success. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Retain the authoritative key reference and inspect the boolean result.
For the delete removes one association chapter on JavaScript WeakMap, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on deleting an equal-looking replacement object and expecting success. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const removed=wm.delete(key);Explained result. removed is true when the key was present; later has(key) is false. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision app. Contrast the rule using private per-instance state maintained by a module. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “delete removes the entry for an exact key and returns whether an entry was removed.” Apply this procedure: Retain the authoritative key reference and inspect the boolean result. The expected mechanism is: removed is true when the key was present; later has(key) is false. For the revision app, add one near-miss that exposes deleting an equal-looking replacement object and expecting success. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: budget dashboard. Stress-test the rule using formatting metadata keyed by row objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “delete removes the entry for an exact key and returns whether an entry was removed.” Apply this procedure: Retain the authoritative key reference and inspect the boolean result. The expected mechanism is: removed is true when the key was present; later has(key) is false. For the budget dashboard, add one near-miss that exposes deleting an equal-looking replacement object and expecting success. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: transport map. Explain the rule using marker information associated with element objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “delete removes the entry for an exact key and returns whether an entry was removed.” Apply this procedure: Retain the authoritative key reference and inspect the boolean result. The expected mechanism is: removed is true when the key was present; later has(key) is false. For the transport map, add one near-miss that exposes deleting an equal-looking replacement object and expecting success. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: debug lab. Transfer the rule using two equal-looking but distinct object identities. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “delete removes the entry for an exact key and returns whether an entry was removed.” Apply this procedure: Retain the authoritative key reference and inspect the boolean result. The expected mechanism is: removed is true when the key was present; later has(key) is false. For the debug lab, add one near-miss that exposes deleting an equal-looking replacement object and expecting success. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers deleting an equal-looking replacement object and expecting success.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Retain the authoritative key reference and inspect the boolean result.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript WeakMap syntax. For this chapter, useful prompts are: “What did you expect from delete removes one association?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing deleting an equal-looking replacement object and expecting success be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny science model with cached derived readings keyed by immutable experiment objects. Include one ordinary case, one boundary and one deliberate failure caused by deleting an equal-looking replacement object and expecting success. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: delete removes the entry for an exact key and returns whether an entry was removed. It shows a trace, not only a final value. The ordinary case should demonstrate “removed is true when the key was present; later has(key) is false.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Retain the authoritative key reference and inspect the boolean result. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For delete removes one association, separate the documented JavaScript WeakMap mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
WeakMap deliberately lacks clear because bulk observation and control would undermine the weak-key lifecycle model. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is calling clear by analogy with Map. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Replace the WeakMap reference when a whole private cache generation must be abandoned.
For the There is no clear method chapter on JavaScript WeakMap, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on calling clear by analogy with Map. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
let cache=new WeakMap();
cache=new WeakMap();Explained result. New lookups use a fresh collection; old entries become collectible when nothing else retains their old map or keys. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: transport map. Stress-test the rule using marker information associated with element objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap deliberately lacks clear because bulk observation and control would undermine the weak-key lifecycle model.” Apply this procedure: Replace the WeakMap reference when a whole private cache generation must be abandoned. The expected mechanism is: New lookups use a fresh collection; old entries become collectible when nothing else retains their old map or keys. For the transport map, add one near-miss that exposes calling clear by analogy with Map. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: debug lab. Explain the rule using two equal-looking but distinct object identities. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap deliberately lacks clear because bulk observation and control would undermine the weak-key lifecycle model.” Apply this procedure: Replace the WeakMap reference when a whole private cache generation must be abandoned. The expected mechanism is: New lookups use a fresh collection; old entries become collectible when nothing else retains their old map or keys. For the debug lab, add one near-miss that exposes calling clear by analogy with Map. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: homework cards. Transfer the rule using object-keyed feedback metadata outside the visible task object. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap deliberately lacks clear because bulk observation and control would undermine the weak-key lifecycle model.” Apply this procedure: Replace the WeakMap reference when a whole private cache generation must be abandoned. The expected mechanism is: New lookups use a fresh collection; old entries become collectible when nothing else retains their old map or keys. For the homework cards, add one near-miss that exposes calling clear by analogy with Map. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: library records. Predict the rule using temporary processing state attached to book objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap deliberately lacks clear because bulk observation and control would undermine the weak-key lifecycle model.” Apply this procedure: Replace the WeakMap reference when a whole private cache generation must be abandoned. The expected mechanism is: New lookups use a fresh collection; old entries become collectible when nothing else retains their old map or keys. For the library records, add one near-miss that exposes calling clear by analogy with Map. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers calling clear by analogy with Map.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Replace the WeakMap reference when a whole private cache generation must be abandoned.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript WeakMap syntax. For this chapter, useful prompts are: “What did you expect from There is no clear method?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing calling clear by analogy with Map be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny revision app with private per-instance state maintained by a module. Include one ordinary case, one boundary and one deliberate failure caused by calling clear by analogy with Map. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: WeakMap deliberately lacks clear because bulk observation and control would undermine the weak-key lifecycle model. It shows a trace, not only a final value. The ordinary case should demonstrate “New lookups use a fresh collection; old entries become collectible when nothing else retains their old map or keys.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Replace the WeakMap reference when a whole private cache generation must be abandoned. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For There is no clear method, separate the documented JavaScript WeakMap mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
WeakMap has no keys, values, entries, iteration or size interface, preventing code from depending on nondeterministic garbage-collection visibility. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is planning a report that lists every WeakMap entry. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use Map when enumeration, counting, persistence or debugging inventory is required.
For the Non-enumeration is a guarantee chapter on JavaScript WeakMap, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on planning a report that lists every WeakMap entry. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
typeof wm.keys; // 'undefined'Explained result. The absence of enumeration is intentional, not a missing convenience method. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: homework cards. Explain the rule using object-keyed feedback metadata outside the visible task object. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap has no keys, values, entries, iteration or size interface, preventing code from depending on nondeterministic garbage-collection visibility.” Apply this procedure: Use Map when enumeration, counting, persistence or debugging inventory is required. The expected mechanism is: The absence of enumeration is intentional, not a missing convenience method. For the homework cards, add one near-miss that exposes planning a report that lists every WeakMap entry. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: library records. Transfer the rule using temporary processing state attached to book objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap has no keys, values, entries, iteration or size interface, preventing code from depending on nondeterministic garbage-collection visibility.” Apply this procedure: Use Map when enumeration, counting, persistence or debugging inventory is required. The expected mechanism is: The absence of enumeration is intentional, not a missing convenience method. For the library records, add one near-miss that exposes planning a report that lists every WeakMap entry. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA interface. Predict the rule using DOM element state removed when elements become unreachable. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap has no keys, values, entries, iteration or size interface, preventing code from depending on nondeterministic garbage-collection visibility.” Apply this procedure: Use Map when enumeration, counting, persistence or debugging inventory is required. The expected mechanism is: The absence of enumeration is intentional, not a missing convenience method. For the CCA interface, add one near-miss that exposes planning a report that lists every WeakMap entry. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: science model. Contrast the rule using cached derived readings keyed by immutable experiment objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap has no keys, values, entries, iteration or size interface, preventing code from depending on nondeterministic garbage-collection visibility.” Apply this procedure: Use Map when enumeration, counting, persistence or debugging inventory is required. The expected mechanism is: The absence of enumeration is intentional, not a missing convenience method. For the science model, add one near-miss that exposes planning a report that lists every WeakMap entry. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers planning a report that lists every WeakMap entry.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Use Map when enumeration, counting, persistence or debugging inventory is required.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript WeakMap syntax. For this chapter, useful prompts are: “What did you expect from Non-enumeration is a guarantee?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing planning a report that lists every WeakMap entry be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny budget dashboard with formatting metadata keyed by row objects. Include one ordinary case, one boundary and one deliberate failure caused by planning a report that lists every WeakMap entry. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: WeakMap has no keys, values, entries, iteration or size interface, preventing code from depending on nondeterministic garbage-collection visibility. It shows a trace, not only a final value. The ordinary case should demonstrate “The absence of enumeration is intentional, not a missing convenience method.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Use Map when enumeration, counting, persistence or debugging inventory is required. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Non-enumeration is a guarantee, separate the documented JavaScript WeakMap mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
A program cannot portably ask whether an unreachable WeakMap key has been collected or when collection occurs. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is forcing garbage collection timing into an application assertion. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Test observable lookup behaviour for live keys and use memory tooling only as non-deterministic diagnostics.
For the Garbage collection is not directly testable chapter on JavaScript WeakMap, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on forcing garbage collection timing into an application assertion. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
wm.set(key,metadata);
// Later dropping external key references creates eligibility, not a deadline.Explained result. The language promises no collection schedule, so correctness must not depend on one. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA interface. Transfer the rule using DOM element state removed when elements become unreachable. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A program cannot portably ask whether an unreachable WeakMap key has been collected or when collection occurs.” Apply this procedure: Test observable lookup behaviour for live keys and use memory tooling only as non-deterministic diagnostics. The expected mechanism is: The language promises no collection schedule, so correctness must not depend on one. For the CCA interface, add one near-miss that exposes forcing garbage collection timing into an application assertion. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: science model. Predict the rule using cached derived readings keyed by immutable experiment objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A program cannot portably ask whether an unreachable WeakMap key has been collected or when collection occurs.” Apply this procedure: Test observable lookup behaviour for live keys and use memory tooling only as non-deterministic diagnostics. The expected mechanism is: The language promises no collection schedule, so correctness must not depend on one. For the science model, add one near-miss that exposes forcing garbage collection timing into an application assertion. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision app. Contrast the rule using private per-instance state maintained by a module. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A program cannot portably ask whether an unreachable WeakMap key has been collected or when collection occurs.” Apply this procedure: Test observable lookup behaviour for live keys and use memory tooling only as non-deterministic diagnostics. The expected mechanism is: The language promises no collection schedule, so correctness must not depend on one. For the revision app, add one near-miss that exposes forcing garbage collection timing into an application assertion. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: budget dashboard. Stress-test the rule using formatting metadata keyed by row objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A program cannot portably ask whether an unreachable WeakMap key has been collected or when collection occurs.” Apply this procedure: Test observable lookup behaviour for live keys and use memory tooling only as non-deterministic diagnostics. The expected mechanism is: The language promises no collection schedule, so correctness must not depend on one. For the budget dashboard, add one near-miss that exposes forcing garbage collection timing into an application assertion. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers forcing garbage collection timing into an application assertion.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Test observable lookup behaviour for live keys and use memory tooling only as non-deterministic diagnostics.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript WeakMap syntax. For this chapter, useful prompts are: “What did you expect from Garbage collection is not directly testable?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing forcing garbage collection timing into an application assertion be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny transport map with marker information associated with element objects. Include one ordinary case, one boundary and one deliberate failure caused by forcing garbage collection timing into an application assertion. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A program cannot portably ask whether an unreachable WeakMap key has been collected or when collection occurs. It shows a trace, not only a final value. The ordinary case should demonstrate “The language promises no collection schedule, so correctness must not depend on one.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Test observable lookup behaviour for live keys and use memory tooling only as non-deterministic diagnostics. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Garbage collection is not directly testable, separate the documented JavaScript WeakMap mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
WeakMap can attach library or application metadata without adding properties to the keyed objects. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is mutating third-party objects with hidden-looking string properties. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Keep one module-owned WeakMap and expose narrow accessor functions.
For the Metadata can stay outside objects chapter on JavaScript WeakMap, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on mutating third-party objects with hidden-looking string properties. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const meta=new WeakMap();
function mark(obj,note){meta.set(obj,{note})}Explained result. The object’s own keys remain unchanged while the module can retrieve metadata by identity. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision app. Predict the rule using private per-instance state maintained by a module. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap can attach library or application metadata without adding properties to the keyed objects.” Apply this procedure: Keep one module-owned WeakMap and expose narrow accessor functions. The expected mechanism is: The object’s own keys remain unchanged while the module can retrieve metadata by identity. For the revision app, add one near-miss that exposes mutating third-party objects with hidden-looking string properties. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: budget dashboard. Contrast the rule using formatting metadata keyed by row objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap can attach library or application metadata without adding properties to the keyed objects.” Apply this procedure: Keep one module-owned WeakMap and expose narrow accessor functions. The expected mechanism is: The object’s own keys remain unchanged while the module can retrieve metadata by identity. For the budget dashboard, add one near-miss that exposes mutating third-party objects with hidden-looking string properties. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: transport map. Stress-test the rule using marker information associated with element objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap can attach library or application metadata without adding properties to the keyed objects.” Apply this procedure: Keep one module-owned WeakMap and expose narrow accessor functions. The expected mechanism is: The object’s own keys remain unchanged while the module can retrieve metadata by identity. For the transport map, add one near-miss that exposes mutating third-party objects with hidden-looking string properties. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: debug lab. Explain the rule using two equal-looking but distinct object identities. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap can attach library or application metadata without adding properties to the keyed objects.” Apply this procedure: Keep one module-owned WeakMap and expose narrow accessor functions. The expected mechanism is: The object’s own keys remain unchanged while the module can retrieve metadata by identity. For the debug lab, add one near-miss that exposes mutating third-party objects with hidden-looking string properties. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers mutating third-party objects with hidden-looking string properties.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Keep one module-owned WeakMap and expose narrow accessor functions.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript WeakMap syntax. For this chapter, useful prompts are: “What did you expect from Metadata can stay outside objects?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing mutating third-party objects with hidden-looking string properties be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny debug lab with two equal-looking but distinct object identities. Include one ordinary case, one boundary and one deliberate failure caused by mutating third-party objects with hidden-looking string properties. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: WeakMap can attach library or application metadata without adding properties to the keyed objects. It shows a trace, not only a final value. The ordinary case should demonstrate “The object’s own keys remain unchanged while the module can retrieve metadata by identity.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Keep one module-owned WeakMap and expose narrow accessor functions. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Metadata can stay outside objects, separate the documented JavaScript WeakMap mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
A closure-scoped WeakMap can hold state keyed by public instances, though modern private fields may be clearer for class-owned state. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is calling closure privacy automatic security against every reference leak. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Limit module access and compare the design with #private fields.
For the Per-instance private state is possible chapter on JavaScript WeakMap, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on calling closure privacy automatic security against every reference leak. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const state=new WeakMap();
class Counter{constructor(){state.set(this,0)}inc(){state.set(this,state.get(this)+1)}}Explained result. Only code with the closure’s state reference can access the stored counts through the instances. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: transport map. Contrast the rule using marker information associated with element objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A closure-scoped WeakMap can hold state keyed by public instances, though modern private fields may be clearer for class-owned state.” Apply this procedure: Limit module access and compare the design with #private fields. The expected mechanism is: Only code with the closure’s state reference can access the stored counts through the instances. For the transport map, add one near-miss that exposes calling closure privacy automatic security against every reference leak. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: debug lab. Stress-test the rule using two equal-looking but distinct object identities. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A closure-scoped WeakMap can hold state keyed by public instances, though modern private fields may be clearer for class-owned state.” Apply this procedure: Limit module access and compare the design with #private fields. The expected mechanism is: Only code with the closure’s state reference can access the stored counts through the instances. For the debug lab, add one near-miss that exposes calling closure privacy automatic security against every reference leak. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: homework cards. Explain the rule using object-keyed feedback metadata outside the visible task object. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A closure-scoped WeakMap can hold state keyed by public instances, though modern private fields may be clearer for class-owned state.” Apply this procedure: Limit module access and compare the design with #private fields. The expected mechanism is: Only code with the closure’s state reference can access the stored counts through the instances. For the homework cards, add one near-miss that exposes calling closure privacy automatic security against every reference leak. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: library records. Transfer the rule using temporary processing state attached to book objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A closure-scoped WeakMap can hold state keyed by public instances, though modern private fields may be clearer for class-owned state.” Apply this procedure: Limit module access and compare the design with #private fields. The expected mechanism is: Only code with the closure’s state reference can access the stored counts through the instances. For the library records, add one near-miss that exposes calling closure privacy automatic security against every reference leak. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers calling closure privacy automatic security against every reference leak.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Limit module access and compare the design with #private fields.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript WeakMap syntax. For this chapter, useful prompts are: “What did you expect from Per-instance private state is possible?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing calling closure privacy automatic security against every reference leak be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny homework cards with object-keyed feedback metadata outside the visible task object. Include one ordinary case, one boundary and one deliberate failure caused by calling closure privacy automatic security against every reference leak. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A closure-scoped WeakMap can hold state keyed by public instances, though modern private fields may be clearer for class-owned state. It shows a trace, not only a final value. The ordinary case should demonstrate “Only code with the closure’s state reference can access the stored counts through the instances.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Limit module access and compare the design with #private fields. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Per-instance private state is possible, separate the documented JavaScript WeakMap mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 13 OF 20 . Debug and verify
13. DOM-associated state follows element lifetime
WeakMap suits auxiliary state keyed by DOM elements when removed elements should not be retained solely by the metadata table. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is keeping the same elements alive in another array and blaming the WeakMap for memory. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Audit all references to the element, event listeners and closures, not just the map.
For the DOM-associated state follows element lifetime chapter on JavaScript WeakMap, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on keeping the same elements alive in another array and blaming the WeakMap for memory. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const uiState=new WeakMap();
uiState.set(button,{clicks:0});Explained result. The association does not by itself require the button to remain alive after every other reference disappears. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: homework cards. Stress-test the rule using object-keyed feedback metadata outside the visible task object. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap suits auxiliary state keyed by DOM elements when removed elements should not be retained solely by the metadata table.” Apply this procedure: Audit all references to the element, event listeners and closures, not just the map. The expected mechanism is: The association does not by itself require the button to remain alive after every other reference disappears. For the homework cards, add one near-miss that exposes keeping the same elements alive in another array and blaming the WeakMap for memory. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: library records. Explain the rule using temporary processing state attached to book objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap suits auxiliary state keyed by DOM elements when removed elements should not be retained solely by the metadata table.” Apply this procedure: Audit all references to the element, event listeners and closures, not just the map. The expected mechanism is: The association does not by itself require the button to remain alive after every other reference disappears. For the library records, add one near-miss that exposes keeping the same elements alive in another array and blaming the WeakMap for memory. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA interface. Transfer the rule using DOM element state removed when elements become unreachable. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap suits auxiliary state keyed by DOM elements when removed elements should not be retained solely by the metadata table.” Apply this procedure: Audit all references to the element, event listeners and closures, not just the map. The expected mechanism is: The association does not by itself require the button to remain alive after every other reference disappears. For the CCA interface, add one near-miss that exposes keeping the same elements alive in another array and blaming the WeakMap for memory. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: science model. Predict the rule using cached derived readings keyed by immutable experiment objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap suits auxiliary state keyed by DOM elements when removed elements should not be retained solely by the metadata table.” Apply this procedure: Audit all references to the element, event listeners and closures, not just the map. The expected mechanism is: The association does not by itself require the button to remain alive after every other reference disappears. For the science model, add one near-miss that exposes keeping the same elements alive in another array and blaming the WeakMap for memory. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers keeping the same elements alive in another array and blaming the WeakMap for memory.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Audit all references to the element, event listeners and closures, not just the map.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript WeakMap syntax. For this chapter, useful prompts are: “What did you expect from DOM-associated state follows element lifetime?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing keeping the same elements alive in another array and blaming the WeakMap for memory be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny library records with temporary processing state attached to book objects. Include one ordinary case, one boundary and one deliberate failure caused by keeping the same elements alive in another array and blaming the WeakMap for memory. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: WeakMap suits auxiliary state keyed by DOM elements when removed elements should not be retained solely by the metadata table. It shows a trace, not only a final value. The ordinary case should demonstrate “The association does not by itself require the button to remain alive after every other reference disappears.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Audit all references to the element, event listeners and closures, not just the map. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For DOM-associated state follows element lifetime, separate the documented JavaScript WeakMap mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
WeakMap can cache derived data for object inputs without preventing otherwise-unused inputs from becoming collectible. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is expecting structurally equal objects to share cached work. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State that identity is the cache key or canonicalise objects elsewhere.
For the Memoising by object identity chapter on JavaScript WeakMap, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on expecting structurally equal objects to share cached work. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
function analyse(obj){if(!cache.has(obj))cache.set(obj,compute(obj));return cache.get(obj)}Explained result. Repeated calls with the same object reuse the result; a new equal object computes separately. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA interface. Explain the rule using DOM element state removed when elements become unreachable. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap can cache derived data for object inputs without preventing otherwise-unused inputs from becoming collectible.” Apply this procedure: State that identity is the cache key or canonicalise objects elsewhere. The expected mechanism is: Repeated calls with the same object reuse the result; a new equal object computes separately. For the CCA interface, add one near-miss that exposes expecting structurally equal objects to share cached work. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: science model. Transfer the rule using cached derived readings keyed by immutable experiment objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap can cache derived data for object inputs without preventing otherwise-unused inputs from becoming collectible.” Apply this procedure: State that identity is the cache key or canonicalise objects elsewhere. The expected mechanism is: Repeated calls with the same object reuse the result; a new equal object computes separately. For the science model, add one near-miss that exposes expecting structurally equal objects to share cached work. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision app. Predict the rule using private per-instance state maintained by a module. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap can cache derived data for object inputs without preventing otherwise-unused inputs from becoming collectible.” Apply this procedure: State that identity is the cache key or canonicalise objects elsewhere. The expected mechanism is: Repeated calls with the same object reuse the result; a new equal object computes separately. For the revision app, add one near-miss that exposes expecting structurally equal objects to share cached work. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: budget dashboard. Contrast the rule using formatting metadata keyed by row objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap can cache derived data for object inputs without preventing otherwise-unused inputs from becoming collectible.” Apply this procedure: State that identity is the cache key or canonicalise objects elsewhere. The expected mechanism is: Repeated calls with the same object reuse the result; a new equal object computes separately. For the budget dashboard, add one near-miss that exposes expecting structurally equal objects to share cached work. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers expecting structurally equal objects to share cached work.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State that identity is the cache key or canonicalise objects elsewhere.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript WeakMap syntax. For this chapter, useful prompts are: “What did you expect from Memoising by object identity?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing expecting structurally equal objects to share cached work be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny CCA interface with DOM element state removed when elements become unreachable. Include one ordinary case, one boundary and one deliberate failure caused by expecting structurally equal objects to share cached work. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: WeakMap can cache derived data for object inputs without preventing otherwise-unused inputs from becoming collectible. It shows a trace, not only a final value. The ordinary case should demonstrate “Repeated calls with the same object reuse the result; a new equal object computes separately.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State that identity is the cache key or canonicalise objects elsewhere. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Memoising by object identity, separate the documented JavaScript WeakMap mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Although keys are weak, a value may strongly reference other objects, including resources or graphs, while its key entry remains live. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is assuming WeakMap makes every object reachable from a value weak. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Trace the value object graph and release resources explicitly when required.
For the Values can retain other objects chapter on JavaScript WeakMap, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assuming WeakMap makes every object reachable from a value weak. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
wm.set(key,{buffer:largeBuffer});Explained result. The buffer is strongly reachable through the value while the key and entry remain live. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision app. Transfer the rule using private per-instance state maintained by a module. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Although keys are weak, a value may strongly reference other objects, including resources or graphs, while its key entry remains live.” Apply this procedure: Trace the value object graph and release resources explicitly when required. The expected mechanism is: The buffer is strongly reachable through the value while the key and entry remain live. For the revision app, add one near-miss that exposes assuming WeakMap makes every object reachable from a value weak. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: budget dashboard. Predict the rule using formatting metadata keyed by row objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Although keys are weak, a value may strongly reference other objects, including resources or graphs, while its key entry remains live.” Apply this procedure: Trace the value object graph and release resources explicitly when required. The expected mechanism is: The buffer is strongly reachable through the value while the key and entry remain live. For the budget dashboard, add one near-miss that exposes assuming WeakMap makes every object reachable from a value weak. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: transport map. Contrast the rule using marker information associated with element objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Although keys are weak, a value may strongly reference other objects, including resources or graphs, while its key entry remains live.” Apply this procedure: Trace the value object graph and release resources explicitly when required. The expected mechanism is: The buffer is strongly reachable through the value while the key and entry remain live. For the transport map, add one near-miss that exposes assuming WeakMap makes every object reachable from a value weak. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: debug lab. Stress-test the rule using two equal-looking but distinct object identities. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Although keys are weak, a value may strongly reference other objects, including resources or graphs, while its key entry remains live.” Apply this procedure: Trace the value object graph and release resources explicitly when required. The expected mechanism is: The buffer is strongly reachable through the value while the key and entry remain live. For the debug lab, add one near-miss that exposes assuming WeakMap makes every object reachable from a value weak. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers assuming WeakMap makes every object reachable from a value weak.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Trace the value object graph and release resources explicitly when required.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript WeakMap syntax. For this chapter, useful prompts are: “What did you expect from Values can retain other objects?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming WeakMap makes every object reachable from a value weak be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny science model with cached derived readings keyed by immutable experiment objects. Include one ordinary case, one boundary and one deliberate failure caused by assuming WeakMap makes every object reachable from a value weak. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Although keys are weak, a value may strongly reference other objects, including resources or graphs, while its key entry remains live. It shows a trace, not only a final value. The ordinary case should demonstrate “The buffer is strongly reachable through the value while the key and entry remain live.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Trace the value object graph and release resources explicitly when required. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Values can retain other objects, separate the documented JavaScript WeakMap mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
A value referring back to its own key does not necessarily keep that key alive solely through the WeakMap entry; the collection is specified with ephemeron-like reachability. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is simplifying the model to an ordinary strong map cycle. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Distinguish outside reachability from paths that begin inside the WeakMap entry.
For the Ephemeron semantics handle key-value cycles chapter on JavaScript WeakMap, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on simplifying the model to an ordinary strong map cycle. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const k={};wm.set(k,{owner:k});Explained result. When no outside reference reaches k, the entry’s internal cycle does not by itself make the key an ordinary strong root. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: transport map. Predict the rule using marker information associated with element objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A value referring back to its own key does not necessarily keep that key alive solely through the WeakMap entry; the collection is specified with ephemeron-like reachability.” Apply this procedure: Distinguish outside reachability from paths that begin inside the WeakMap entry. The expected mechanism is: When no outside reference reaches k, the entry’s internal cycle does not by itself make the key an ordinary strong root. For the transport map, add one near-miss that exposes simplifying the model to an ordinary strong map cycle. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: debug lab. Contrast the rule using two equal-looking but distinct object identities. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A value referring back to its own key does not necessarily keep that key alive solely through the WeakMap entry; the collection is specified with ephemeron-like reachability.” Apply this procedure: Distinguish outside reachability from paths that begin inside the WeakMap entry. The expected mechanism is: When no outside reference reaches k, the entry’s internal cycle does not by itself make the key an ordinary strong root. For the debug lab, add one near-miss that exposes simplifying the model to an ordinary strong map cycle. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: homework cards. Stress-test the rule using object-keyed feedback metadata outside the visible task object. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A value referring back to its own key does not necessarily keep that key alive solely through the WeakMap entry; the collection is specified with ephemeron-like reachability.” Apply this procedure: Distinguish outside reachability from paths that begin inside the WeakMap entry. The expected mechanism is: When no outside reference reaches k, the entry’s internal cycle does not by itself make the key an ordinary strong root. For the homework cards, add one near-miss that exposes simplifying the model to an ordinary strong map cycle. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: library records. Explain the rule using temporary processing state attached to book objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A value referring back to its own key does not necessarily keep that key alive solely through the WeakMap entry; the collection is specified with ephemeron-like reachability.” Apply this procedure: Distinguish outside reachability from paths that begin inside the WeakMap entry. The expected mechanism is: When no outside reference reaches k, the entry’s internal cycle does not by itself make the key an ordinary strong root. For the library records, add one near-miss that exposes simplifying the model to an ordinary strong map cycle. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers simplifying the model to an ordinary strong map cycle.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Distinguish outside reachability from paths that begin inside the WeakMap entry.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript WeakMap syntax. For this chapter, useful prompts are: “What did you expect from Ephemeron semantics handle key-value cycles?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing simplifying the model to an ordinary strong map cycle be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny revision app with private per-instance state maintained by a module. Include one ordinary case, one boundary and one deliberate failure caused by simplifying the model to an ordinary strong map cycle. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A value referring back to its own key does not necessarily keep that key alive solely through the WeakMap entry; the collection is specified with ephemeron-like reachability. It shows a trace, not only a final value. The ordinary case should demonstrate “When no outside reference reaches k, the entry’s internal cycle does not by itself make the key an ordinary strong root.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Distinguish outside reachability from paths that begin inside the WeakMap entry. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Ephemeron semantics handle key-value cycles, separate the documented JavaScript WeakMap mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 17 OF 20 . Transfer with judgment
17. Frozen and sealed objects remain valid keys
Object extensibility is unrelated to WeakMap key identity, so frozen or sealed objects can be keys. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is adding a property to prove metadata storage and failing on a frozen object. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Store auxiliary information in the WeakMap and test the object remains unchanged.
For the Frozen and sealed objects remain valid keys chapter on JavaScript WeakMap, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on adding a property to prove metadata storage and failing on a frozen object. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const k=Object.freeze({id:1});wm.set(k,'ready');Explained result. The association works because the WeakMap does not need to modify k. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: homework cards. Contrast the rule using object-keyed feedback metadata outside the visible task object. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Object extensibility is unrelated to WeakMap key identity, so frozen or sealed objects can be keys.” Apply this procedure: Store auxiliary information in the WeakMap and test the object remains unchanged. The expected mechanism is: The association works because the WeakMap does not need to modify k. For the homework cards, add one near-miss that exposes adding a property to prove metadata storage and failing on a frozen object. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: library records. Stress-test the rule using temporary processing state attached to book objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Object extensibility is unrelated to WeakMap key identity, so frozen or sealed objects can be keys.” Apply this procedure: Store auxiliary information in the WeakMap and test the object remains unchanged. The expected mechanism is: The association works because the WeakMap does not need to modify k. For the library records, add one near-miss that exposes adding a property to prove metadata storage and failing on a frozen object. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA interface. Explain the rule using DOM element state removed when elements become unreachable. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Object extensibility is unrelated to WeakMap key identity, so frozen or sealed objects can be keys.” Apply this procedure: Store auxiliary information in the WeakMap and test the object remains unchanged. The expected mechanism is: The association works because the WeakMap does not need to modify k. For the CCA interface, add one near-miss that exposes adding a property to prove metadata storage and failing on a frozen object. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: science model. Transfer the rule using cached derived readings keyed by immutable experiment objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Object extensibility is unrelated to WeakMap key identity, so frozen or sealed objects can be keys.” Apply this procedure: Store auxiliary information in the WeakMap and test the object remains unchanged. The expected mechanism is: The association works because the WeakMap does not need to modify k. For the science model, add one near-miss that exposes adding a property to prove metadata storage and failing on a frozen object. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers adding a property to prove metadata storage and failing on a frozen object.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Store auxiliary information in the WeakMap and test the object remains unchanged.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript WeakMap syntax. For this chapter, useful prompts are: “What did you expect from Frozen and sealed objects remain valid keys?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing adding a property to prove metadata storage and failing on a frozen object be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny budget dashboard with formatting metadata keyed by row objects. Include one ordinary case, one boundary and one deliberate failure caused by adding a property to prove metadata storage and failing on a frozen object. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Object extensibility is unrelated to WeakMap key identity, so frozen or sealed objects can be keys. It shows a trace, not only a final value. The ordinary case should demonstrate “The association works because the WeakMap does not need to modify k.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Store auxiliary information in the WeakMap and test the object remains unchanged. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Frozen and sealed objects remain valid keys, separate the documented JavaScript WeakMap mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
WeakMap retrieves a value only through a live key; WeakRef directly offers a non-owning reference whose deref may return undefined. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is substituting one merely because both mention weak references. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Name the access path and lifecycle requirement before choosing either API.
For the WeakMap differs from WeakRef chapter on JavaScript WeakMap, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on substituting one merely because both mention weak references. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const ref=new WeakRef(obj);
const value=ref.deref();Explained result. WeakRef exposes a weak reference to one target; WeakMap is an identity-keyed association with no enumeration. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA interface. Stress-test the rule using DOM element state removed when elements become unreachable. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap retrieves a value only through a live key; WeakRef directly offers a non-owning reference whose deref may return undefined.” Apply this procedure: Name the access path and lifecycle requirement before choosing either API. The expected mechanism is: WeakRef exposes a weak reference to one target; WeakMap is an identity-keyed association with no enumeration. For the CCA interface, add one near-miss that exposes substituting one merely because both mention weak references. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: science model. Explain the rule using cached derived readings keyed by immutable experiment objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap retrieves a value only through a live key; WeakRef directly offers a non-owning reference whose deref may return undefined.” Apply this procedure: Name the access path and lifecycle requirement before choosing either API. The expected mechanism is: WeakRef exposes a weak reference to one target; WeakMap is an identity-keyed association with no enumeration. For the science model, add one near-miss that exposes substituting one merely because both mention weak references. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision app. Transfer the rule using private per-instance state maintained by a module. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap retrieves a value only through a live key; WeakRef directly offers a non-owning reference whose deref may return undefined.” Apply this procedure: Name the access path and lifecycle requirement before choosing either API. The expected mechanism is: WeakRef exposes a weak reference to one target; WeakMap is an identity-keyed association with no enumeration. For the revision app, add one near-miss that exposes substituting one merely because both mention weak references. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: budget dashboard. Predict the rule using formatting metadata keyed by row objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap retrieves a value only through a live key; WeakRef directly offers a non-owning reference whose deref may return undefined.” Apply this procedure: Name the access path and lifecycle requirement before choosing either API. The expected mechanism is: WeakRef exposes a weak reference to one target; WeakMap is an identity-keyed association with no enumeration. For the budget dashboard, add one near-miss that exposes substituting one merely because both mention weak references. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers substituting one merely because both mention weak references.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Name the access path and lifecycle requirement before choosing either API.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript WeakMap syntax. For this chapter, useful prompts are: “What did you expect from WeakMap differs from WeakRef?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing substituting one merely because both mention weak references be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny transport map with marker information associated with element objects. Include one ordinary case, one boundary and one deliberate failure caused by substituting one merely because both mention weak references. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: WeakMap retrieves a value only through a live key; WeakRef directly offers a non-owning reference whose deref may return undefined. It shows a trace, not only a final value. The ordinary case should demonstrate “WeakRef exposes a weak reference to one target; WeakMap is an identity-keyed association with no enumeration.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Name the access path and lifecycle requirement before choosing either API. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For WeakMap differs from WeakRef, separate the documented JavaScript WeakMap mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Deterministic tests should cover set, get, has, delete, identity separation and primitive rejection, not collection timing. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is writing a flaky timeout that expects memory to be reclaimed. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Keep strong references during assertions and treat memory observations as optional profiling evidence.
For the Testing focuses on live keys chapter on JavaScript WeakMap, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on writing a flaky timeout that expects memory to be reclaimed. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const a={},b={};const wm=new WeakMap([[a,1]]);
console.assert(wm.get(a)===1&&!wm.has(b));Explained result. The test proves observable semantics without assuming when a garbage collector runs. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision app. Explain the rule using private per-instance state maintained by a module. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Deterministic tests should cover set, get, has, delete, identity separation and primitive rejection, not collection timing.” Apply this procedure: Keep strong references during assertions and treat memory observations as optional profiling evidence. The expected mechanism is: The test proves observable semantics without assuming when a garbage collector runs. For the revision app, add one near-miss that exposes writing a flaky timeout that expects memory to be reclaimed. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: budget dashboard. Transfer the rule using formatting metadata keyed by row objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Deterministic tests should cover set, get, has, delete, identity separation and primitive rejection, not collection timing.” Apply this procedure: Keep strong references during assertions and treat memory observations as optional profiling evidence. The expected mechanism is: The test proves observable semantics without assuming when a garbage collector runs. For the budget dashboard, add one near-miss that exposes writing a flaky timeout that expects memory to be reclaimed. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: transport map. Predict the rule using marker information associated with element objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Deterministic tests should cover set, get, has, delete, identity separation and primitive rejection, not collection timing.” Apply this procedure: Keep strong references during assertions and treat memory observations as optional profiling evidence. The expected mechanism is: The test proves observable semantics without assuming when a garbage collector runs. For the transport map, add one near-miss that exposes writing a flaky timeout that expects memory to be reclaimed. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: debug lab. Contrast the rule using two equal-looking but distinct object identities. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Deterministic tests should cover set, get, has, delete, identity separation and primitive rejection, not collection timing.” Apply this procedure: Keep strong references during assertions and treat memory observations as optional profiling evidence. The expected mechanism is: The test proves observable semantics without assuming when a garbage collector runs. For the debug lab, add one near-miss that exposes writing a flaky timeout that expects memory to be reclaimed. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers writing a flaky timeout that expects memory to be reclaimed.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Keep strong references during assertions and treat memory observations as optional profiling evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript WeakMap syntax. For this chapter, useful prompts are: “What did you expect from Testing focuses on live keys?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing writing a flaky timeout that expects memory to be reclaimed be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny debug lab with two equal-looking but distinct object identities. Include one ordinary case, one boundary and one deliberate failure caused by writing a flaky timeout that expects memory to be reclaimed. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Deterministic tests should cover set, get, has, delete, identity separation and primitive rejection, not collection timing. It shows a trace, not only a final value. The ordinary case should demonstrate “The test proves observable semantics without assuming when a garbage collector runs.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Keep strong references during assertions and treat memory observations as optional profiling evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Testing focuses on live keys, separate the documented JavaScript WeakMap mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
WeakMap is appropriate for non-enumerable auxiliary data whose object keys should not be retained by the collection; Map, private fields or ordinary properties suit other contracts. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is choosing WeakMap as a generic memory optimisation without an identity-lifecycle reason. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Write requirements for key type, enumeration, persistence, debugging and ownership before selecting it.
For the Choose WeakMap with judgment chapter on JavaScript WeakMap, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on choosing WeakMap as a generic memory optimisation without an identity-lifecycle reason. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
// Need a count or list of keys? Choose Map instead.Explained result. Mastery is recognising that weak lifetime and non-enumeration are a paired contract, not independent options. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: transport map. Transfer the rule using marker information associated with element objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap is appropriate for non-enumerable auxiliary data whose object keys should not be retained by the collection; Map, private fields or ordinary properties suit other contracts.” Apply this procedure: Write requirements for key type, enumeration, persistence, debugging and ownership before selecting it. The expected mechanism is: Mastery is recognising that weak lifetime and non-enumeration are a paired contract, not independent options. For the transport map, add one near-miss that exposes choosing WeakMap as a generic memory optimisation without an identity-lifecycle reason. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: debug lab. Predict the rule using two equal-looking but distinct object identities. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap is appropriate for non-enumerable auxiliary data whose object keys should not be retained by the collection; Map, private fields or ordinary properties suit other contracts.” Apply this procedure: Write requirements for key type, enumeration, persistence, debugging and ownership before selecting it. The expected mechanism is: Mastery is recognising that weak lifetime and non-enumeration are a paired contract, not independent options. For the debug lab, add one near-miss that exposes choosing WeakMap as a generic memory optimisation without an identity-lifecycle reason. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: homework cards. Contrast the rule using object-keyed feedback metadata outside the visible task object. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap is appropriate for non-enumerable auxiliary data whose object keys should not be retained by the collection; Map, private fields or ordinary properties suit other contracts.” Apply this procedure: Write requirements for key type, enumeration, persistence, debugging and ownership before selecting it. The expected mechanism is: Mastery is recognising that weak lifetime and non-enumeration are a paired contract, not independent options. For the homework cards, add one near-miss that exposes choosing WeakMap as a generic memory optimisation without an identity-lifecycle reason. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: library records. Stress-test the rule using temporary processing state attached to book objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “WeakMap is appropriate for non-enumerable auxiliary data whose object keys should not be retained by the collection; Map, private fields or ordinary properties suit other contracts.” Apply this procedure: Write requirements for key type, enumeration, persistence, debugging and ownership before selecting it. The expected mechanism is: Mastery is recognising that weak lifetime and non-enumeration are a paired contract, not independent options. For the library records, add one near-miss that exposes choosing WeakMap as a generic memory optimisation without an identity-lifecycle reason. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers choosing WeakMap as a generic memory optimisation without an identity-lifecycle reason.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Write requirements for key type, enumeration, persistence, debugging and ownership before selecting it.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript WeakMap syntax. For this chapter, useful prompts are: “What did you expect from Choose WeakMap with judgment?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing choosing WeakMap as a generic memory optimisation without an identity-lifecycle reason be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny homework cards with object-keyed feedback metadata outside the visible task object. Include one ordinary case, one boundary and one deliberate failure caused by choosing WeakMap as a generic memory optimisation without an identity-lifecycle reason. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: WeakMap is appropriate for non-enumerable auxiliary data whose object keys should not be retained by the collection; Map, private fields or ordinary properties suit other contracts. It shows a trace, not only a final value. The ordinary case should demonstrate “Mastery is recognising that weak lifetime and non-enumeration are a paired contract, not independent options.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Write requirements for key type, enumeration, persistence, debugging and ownership before selecting it. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Choose WeakMap with judgment, separate the documented JavaScript WeakMap mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Parent guide: choose the next useful step
Start with evidence, not a label such as careless. Ask for one prediction and one trace. If the first transition is wrong, rebuild the model. If the model is sound but syntax fails, practise reference use. If routine cases are correct but boundaries fail, vary ties, defaults, unsupported inputs, ownership or missing paths. If explanations transfer, move to a small project.
Keep a weekly record with four lines: concept, prediction, observed difference and next test. Stop when fatigue replaces reasoning. A smaller case tomorrow is more useful than another hour of copying tonight.
Seek specialist help when cause and effect remain invisible after examples are reduced, when accessibility or data-loss implications are unclear, or when an important repository, database or application state may be at risk. Good support should make the learner’s reasoning more independent.
Capstone practice with explained routes
1. homework cards: model, boundary and recovery
Create a small homework cards using object-keyed feedback metadata outside the visible task object. Combine “Weak keys and strong values” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: A WeakMap holds its keys weakly but retains each associated value as long as the key remains reachable and the entry exists. Apply: Draw external references to key and value separately, then remove only one reference at a time. Verify: The object key can participate without the WeakMap alone keeping it alive; get(key) returns the strongly associated value while key is reachable. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
2. library records: model, boundary and recovery
Create a small library records using temporary processing state attached to book objects. Combine “set returns the WeakMap” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: set associates a value with a valid key and returns the WeakMap, enabling deliberate chaining. Apply: Inspect identity of the returned collection and retrieve the value separately. Verify: returned === wm, while wm.get(k) is 42. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
3. CCA interface: model, boundary and recovery
Create a small CCA interface using DOM element state removed when elements become unreachable. Combine “delete removes one association” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: delete removes the entry for an exact key and returns whether an entry was removed. Apply: Retain the authoritative key reference and inspect the boolean result. Verify: removed is true when the key was present; later has(key) is false. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
4. science model: model, boundary and recovery
Create a small science model using cached derived readings keyed by immutable experiment objects. Combine “Garbage collection is not directly testable” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: A program cannot portably ask whether an unreachable WeakMap key has been collected or when collection occurs. Apply: Test observable lookup behaviour for live keys and use memory tooling only as non-deterministic diagnostics. Verify: The language promises no collection schedule, so correctness must not depend on one. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
5. revision app: model, boundary and recovery
Create a small revision app using private per-instance state maintained by a module. Combine “DOM-associated state follows element lifetime” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: WeakMap suits auxiliary state keyed by DOM elements when removed elements should not be retained solely by the metadata table. Apply: Audit all references to the element, event listeners and closures, not just the map. Verify: The association does not by itself require the button to remain alive after every other reference disappears. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
6. budget dashboard: model, boundary and recovery
Create a small budget dashboard using formatting metadata keyed by row objects. Combine “Ephemeron semantics handle key-value cycles” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: A value referring back to its own key does not necessarily keep that key alive solely through the WeakMap entry; the collection is specified with ephemeron-like reachability. Apply: Distinguish outside reachability from paths that begin inside the WeakMap entry. Verify: When no outside reference reaches k, the entry’s internal cycle does not by itself make the key an ordinary strong root. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
7. transport map: model, boundary and recovery
Create a small transport map using marker information associated with element objects. Combine “Testing focuses on live keys” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: Deterministic tests should cover set, get, has, delete, identity separation and primitive rejection, not collection timing. Apply: Keep strong references during assertions and treat memory observations as optional profiling evidence. Verify: The test proves observable semantics without assuming when a garbage collector runs. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
8. debug lab: model, boundary and recovery
Create a small debug lab using two equal-looking but distinct object identities. Combine “Valid keys follow the current language contract” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: WeakMap keys must be objects or non-registered symbols under the current ECMAScript contract; ordinary primitives and registered symbols are rejected. Apply: Validate key type at the boundary and use Map when primitive keys are part of the model. Verify: An object is a valid identity key; wm.set(‘id’,’x’) throws TypeError. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
Frequently asked questions
How long should a practice session be?
Use one complete prediction–observation–explanation cycle while attention remains good. Ten to twenty focused minutes can be enough.
Should every option or function be memorised?
No. Memorise the governing distinctions and practise retrieving the official reference. Understanding means predicting and explaining, not reciting a parameter list.
What if the result is correct but the explanation is weak?
Treat it as partial success. Ask for a trace and change one boundary. A reliable model survives controlled variation.
Is the shortest solution the best?
Not automatically. Prefer the solution whose semantics, failure modes and maintenance cost are easiest to justify for the actual project.
When should official documentation be used?
Use it whenever syntax, supported types, SQL dialect behaviour or Git version details matter. Primary documentation settles the current contract.
How can a parent help without technical expertise?
Ask what was predicted, where the first difference appeared, what evidence matters and which smaller example could isolate it.
How do we test transfer?
Change the context, vocabulary and one boundary. Require the learner to identify the invariant before using a tool.
What should be saved after practice?
Keep the corrected rule, one trace, one boundary case and the next question. Avoid storing pages of unexplained output.
Can these exercises replace backups?
No. Use disposable examples and proper backups. Learning should not endanger schoolwork, repositories or personal data.
What counts as mastery?
The learner can predict, verify, diagnose, recover and justify a choice across more than one context, while knowing when to consult the current reference.
