Structured Data in Go

Table of Contents

1. Challenge

   Step 1: Orient yourself with the manifest tool scenario and toolchain

   Globomantics needs a manifest tool

   Globomantics loads pallets onto delivery trucks every morning, and right now nobody has a reliable way to see what is loaded where. Throughout this lab, you will build a small command-line manifest tool in Go that models three kinds of data the dispatcher cares about: a fixed set of truck bins, a growing queue of shipment pallets, and a warehouse of pallet records keyed by ID. Each step adds one file to a shared module, and the last step wires all three into a single printed report.

   You will write real Go source across seven files: main.go (the entry point), values.go (constants and pointer semantics), bins.go and shipments.go (arrays and slices), pallet.go and warehouse.go (structs and maps), and manifest.go (the final report). Every file already exists as a starter stub with // TODO markers; you fill in the marked functions, you never create new files. ## Confirm your toolchain before writing code

   Before touching the manifest files, make sure your editor and Go installation agree on the same version this lab expects.

   1. Look over the lab's editor: each source file you will change opens as its own tab, and the Terminal tab gives you a shell for running Go commands.
   2. Open a terminal in the workspace root and run go version. It must report go1.26. If it reports something else, your PATH is pointing at a different install and the graded checks will not match what you see locally.
   3. Run go env GOMOD from the workspace root. It should print the path to this workspace's go.mod. If it prints nothing, your terminal is not sitting in the workspace root; cd there before continuing.

   Once go version and go env GOMOD both report correctly, you are ready to start editing files in Step 2. ## How the pieces fit together

   Keep this map in mind as you move through the steps:

   • Step 2 gives you a runnable entry point and the constants describing truck capacity and pallet weight, plus your first look at how Go tells a value copy apart from a pointer-based update.
   • Step 3 adds a fixed array of bin totals and a growable slice of shipment weights, then shows you the sharp edge of slicing: two slices can secretly point at the same backing storage.
   • Step 4 models each pallet as a struct and stores pallets by ID in a map, then forces you to write a real deep clone so a copy of the warehouse can't corrupt the original.
   • Step 5 combines everything into one Manifest type with a total-weight calculation and a formatted report, called from the main you wrote in Step 2.

   Each task you complete replaces the // TODO markers in one file. Nothing you write is thrown away: when you run the program in Step 6, main calls nearly every function you built. Only the three demonstrations IncreaseWeightCopy, BinView, and MutateSubSlice are exercised solely by their checks.

2. Challenge

   Step 2: Build the manifest entry point and core values

   Every Go program starts at main

   A Go module's executable entry point is the main function inside package main. When you run go run . or build the module, Go finds this function and runs it first, nothing else executes on its own. Printing output from main is the job of the fmt package: fmt.Println writes a line to standard output followed by a newline, which is exactly what the dispatcher's manifest report needs for its header.

   main.go in this workspace already declares package main and imports fmt; the rest of main, beneath the header's TODO, already calls the helper functions you will implement in later tasks, so you only add the header line itself. ## Constants, variables, and formatted strings

   Go distinguishes constants (const), which are fixed at compile time and can never change, from variables (var), which can be reassigned while the program runs. Truck capacity is a good fit for a constant, since it never changes for a given truck model, while a default pallet weight might reasonably vary, so it lives in a variable. values.go declares both for you already.

   To combine multiple values into one readable line, fmt.Sprintf works like Println but returns the formatted string instead of printing it, using %d (or %v) placeholders for the values you pass in. ## Value copies versus pointer updates

   When you pass an int to a Go function, the function receives its own independent copy, changing that copy inside the function has no effect on the caller's variable. A pointer, written *int, instead holds the memory address of the caller's variable, so writing through it with *ptr = newValue (or *ptr += delta) changes the original.

   This distinction matters constantly in the manifest tool: whenever one part of the program needs to update a value another part is holding onto, it needs a pointer, not a copy. values.go declares both versions for you: IncreaseWeightCopy takes a plain int and IncreasePalletWeight takes an *int. You supply the bodies.

3. Challenge

   Step 3: Track bins and shipments with arrays and slices

   Fixed arrays for a fixed number of bins

   Every Globomantics truck has exactly four cargo bins; that number never changes, so Go's fixed-size array type, written [4]int, is the right fit. An array's length is part of its type: [4]int and [5]int are different types entirely, and the length can never grow or shrink at runtime. Array values are also copied whole when assigned or returned, which is why returning an array by value gives the caller an independent snapshot rather than a shared reference.

   bins.go declares InitializeBins, which returns [4]int, and BinView, which takes a pointer to that array. Slicing an array with bins[:] produces a slice that points at the array's own storage instead of copying it, a first look at the shared-storage behavior Task 3.3 returns to. ## Slices grow where arrays can't

   Unlike bins, the number of shipment pallets arriving each morning is unpredictable, so shipments.go tracks pallet weights in a slice, []int, instead of an array. A slice is a small header (pointer, length, capacity) pointing at an underlying array, and Go's built-in append function adds an element, growing the underlying array and copying to a new one behind the scenes whenever the current one runs out of room.

   Because append can return a slice backed by a different array than the one you passed in, you must always use the slice append returns, discarding it silently drops the added element from the caller's point of view. ## When two slices share one backing array

   Here is the sharp edge: slicing an existing slice with s[low:high] does not copy anything. The result is a new slice header pointing at the same backing array as s, just with a different starting point and length. Mutating an element through either slice changes the data both slices see, because there is only ever one array underneath.

   This is a common source of bugs when code assumes slicing behaves like copying. In shipments.go you will deliberately trigger this behavior to see it firsthand, so you recognize it later when it happens by accident.

4. Challenge

   Step 4: Model warehouse records with structs and maps

   Structs model one pallet's fields together

   A Go struct groups related fields under one type, similar to a class with only data and no methods (yet). pallet.go declares a Pallet struct with an ID, a Zone, a Weight, and a Tags []string field for notes like "fragile" or "refrigerated". Building every pallet through one constructor function, rather than writing struct literals all over the codebase, keeps that shape consistent.

   Because Tags is itself a slice, the same shared-backing-array behavior you just saw with shipments applies here too, something you'll need to remember again in the next block. ## Maps index records by key

   A Go map[string]Pallet associates each pallet's ID with its full record, giving constant-time lookup by key instead of scanning a slice. Writing to a map uses index syntax, m[key] = value, and writing to a key that already exists simply overwrites the previous value; there is no separate "insert vs update" step to worry about.

   warehouse.go declares the warehouse as map[string]Pallet, keyed by each pallet's ID field, so any part of the program can find a pallet's record without searching. ## Why a map copy isn't a deep clone

   Assigning one map variable to another, clone := original, does not copy the map's contents; both variables end up pointing at the same underlying table, so writes through either one are visible through both. Even if you copy entry-by-entry into a brand-new map, each Pallet value you copy still has a Tags field, and copying a struct copies its slice header, not the slice's contents; so both copies would still share one Tags backing array.

   A true deep clone has to walk two levels: a new map, and inside it, a new slice for every Tags field. warehouse.go needs exactly that.

5. Challenge

   Step 5: Wire the manifest report together

   One type to hold the whole manifest

   manifest.go declares a Manifest struct with three fields: Bins [4]int, Shipments []int, and Warehouse map[string]Pallet, exactly the three data shapes you built in Steps 3 and 4. A constructor function that takes each piece as a parameter and assembles one Manifest value keeps the assembly logic in one place, so nothing downstream has to know how the three pieces were built. ## Methods attach behavior to a type

   A Go method is a function with a receiver, such as func (m Manifest) TotalWeight() int attaches TotalWeight to every Manifest value, callable as m.TotalWeight(). Because the receiver here is a value, not a pointer, the method reads m's fields without risk of accidentally modifying the caller's manifest.

   Totaling the manifest means walking all three fields (bins, shipments, and every pallet currently sitting in the warehouse) and adding every weight into one running sum. ## Turning data into a report a human reads

   The dispatcher doesn't want to inspect Go values in a debugger; they want a printed report. fmt.Sprintf with \n between segments builds a multi-line string entirely in memory, which main.go then prints in one call as the last part of its output. This is the same pattern you used for TruckCapacityReport in Step 2, just combining more values: the manifest's total weight, its bin count, and its shipment count.

   Once this function returns real data, running the program produces the complete manifest end to end.

6. Challenge

   Step 6: Run the application

   Now that all the tasks are done, run the whole app and watch everything work together. This is the first time the pieces you wrote separately come together as one program.

   Start the application

   Open the Terminal tab and run:

   go run .
   

   You should see the header, the capacity line, the draft-clone check, and then the manifest report:

   === Globomantics Manifest ===
   Truck capacity: 2800 lbs, pallet weight: 150 lbs
   Draft P1: 175 lbs [inspected]; warehouse P1: 150 lbs [fragile]
   Total Weight: 2065
   Bins: 4
   Shipments: 2
   

   The draft line shows the deep clone at work: the draft copy of pallet P1 was reweighed through a pointer and retagged, while the warehouse record kept its original weight and tag. The total of 2065 pounds stays under the truck's 2800-pound capacity.

   The program runs in the terminal and prints its output there. Every behavior it shows is code you wrote in the previous steps, so read the output against what each task asked for. That is the whole lab, working as one program. Congratulations on completing the lab!