Ch08 Discussion

Discussion Guide

Warm-up (think–pair–share, 5 min). "In any language you know, what goes wrong when a program grows past one file and everything is global?" Surfaces name clashes, unclear ownership, and fear of changing shared state — exactly what modules fix. Bridge: "FORTRAN 77 had only the global option; modules were the cure."

Main discussion (15–20 min). 1. Wall vs folder. Put a private module variable on the board and ask: "How can code outside change it?" Answer: only through public procedures. Then ask why that is worth giving up the convenience of a public variable. Teaches encapsulation as a guarantee, not a style. 2. The silent bug. Present Case Study 1's two COMMON declarations. Have the class find the mismatch, then ask: "Which safety net should have caught this, and why did each fail?" Reveal that no single compilation unit can see the contradiction — and that the module makes it a compile error. This is the emotional core of §8.4. 3. Where's the boundary? Pose Case Study 2's cycle (heat_solver uses heat_io, heat_io uses heat_solver). Poll: refactor down, or submodule? Draw out that the cycle means a responsibility (I/O inside step) is misplaced. Teaches that a circular-dependency error is design feedback.

Group activity (10 min). In pairs, hand each group a list of 6–8 responsibilities for a small simulation (e.g., kinds, config, grid, physics, boundary conditions, I/O, timers, driver). Have them (a) group into modules, (b) draw the dependency graph, and (c) write the compile order. Collect two or three and compare — the interesting disagreements are always about where I/O and boundary conditions belong. Reinforce: acyclic + shallow + one-job-per-module.

Exit ticket. "You get Cannot open module file 'grid.mod', but grid.f90 is correct. In one sentence, what is wrong and how do you fix it?" (Checks the §8.5 core: compile grid first / fix the order / -I. Anything about compile order is a pass; anything about the module being 'broken' is a miss to revisit.)