Chapter 9 — Teaching Notes

One-line purpose. Move students from computing in Fortran to designing in it: bundle related data into derived types, attach behaviour with type-bound procedures, and get value semantics from allocatable components — the structural foundation the whole rest of the book (and Chapter 10's OOP) stands on.

Key ideas to emphasize

  • class, not type, on the passed object. This is the single most common compile error of the chapter. Say it, write it on the board, and have them hit the error deliberately (Exercise 9.17). Explain the why (a passed object must be polymorphic so an extension can inherit it) even though extension isn't until Chapter 10 — otherwise "always write class" feels arbitrary.
  • Allocatable components give value semantics. The b = a deep-copy is the chapter's most important practical idea. Contrast it live with what a pointer component would do (shallow alias). Example 3 and Exercise 9.8 are built for this — run the deep-copy demo and show a is untouched after mutating b.
  • Data structures are primary. The Brooks epigraph is the frame: get the data layout right and the code reads like the science. The parallel-arrays-to-body-type refactor (Case Study 1) is the vivid version.
  • Honest about PDTs. Teach parameterized derived types for recognition, but be explicit that gfortran's support is the weakest corner of modern Fortran and that allocatable components are the portable workhorse. Modeling this honesty ("recognize the feature, reach for the alternative") is itself a lesson.

Misconceptions to preempt

  • "Declare the passed object type(circle)." → Must be class(circle); the compiler rejects type.
  • "b = a on a type with a pointer component makes an independent copy." → No — it aliases. Only allocatable components deep-copy.
  • "Type-bound procedures are slow (dynamic dispatch)." → Not here — without polymorphism the call inlines to a direct call; dispatch cost is a Chapter 10 topic and only when the dynamic type is unknown.
  • "Derived types are slower, so HPC avoids them." → Half-myth: an array of a type is Array-of-Structures, which is fine (often ideal) for whole-object loops and only a penalty for single-field sweeps. Layout, not "types," decides. (Case Study 1.)
  • "Parameterized derived types just work everywhere." → They often don't; test or use allocatable components.

A live demonstration (5–8 minutes)

Compile and run code/example-03-allocatable-components.f90. Show the last two output lines: a%val(1) = 20.000 while b%val(1) = 99.000 after b = a; b%values(1) = 99. Then, on a slide (do not compile — it's the counterfactual), change values to real(dp), pointer :: values(:) and ask the class to predict what a%val(1) would print. The answer (99.000) makes the deep-copy guarantee unforgettable. Optionally, on godbolt.org with gfortran, show c%area() compiling to a direct call — methods are free.

Class-time budget (~50 min)

  • 8 min: §9.1 types, components, %, nested types, structure constructors (Example 1).
  • 12 min: §9.2 type-bound procedures, the class passed object, pass/nopass (Example 2 + the bug).
  • 6 min: §9.3 parameterized derived types — recognize, and the honest compiler caveat.
  • 14 min: §9.4 constructors + allocatable components + the deep-copy live demo (Example 3).
  • 6 min: §9.5 designing scientific structures (particle, grid cell, labeled field).
  • 4 min: Project Checkpoint — build field_t; why one argument beats five.

Prerequisites to review

Ch. 5 (allocatable arrays, whole-array intrinsics sum/minval/maxval/size, column-major), Ch. 8 (modules, public/private, explicit interfaces), Ch. 6 (intent, pure), Ch. 3 (dp). A two-minute recap of "what allocate does and when an allocatable array is auto-deallocated" pays off directly in §9.4.

Connections

Backward: Ch. 5 (arrays → allocatable components), Ch. 8 (modules host the types). Forward: Ch. 10 (OOP — extends, class, select type — is built entirely on this chapter; the class you wrote here is cashed in there), Ch. 11 (the full allocatable-vs-pointer case), Ch. 12 (deferred-length character components), Ch. 24/38 (the field_t becomes the solver's spine). Naming these now motivates the "always write class" rule and the allocatable preference.