One owner for what the iPod can play #16

Merged
wokoman merged 1 commit from refactor/one-format-owner into main 2026-08-28 20:04:38 +02:00
Owner

One module owns what the iPod can play — the extensions, and the names libgpod uses for them. Copying and transcoding both read from it, and neither reaches into the other.

Before this, the two split format policy and depended on each other in both directions: the transcoder called into the copy engine to ask whether a file was playable, while separately restating the same libgpod format strings the copy engine's table already held. Adding a format meant editing two tables that had to agree, and the module cycle is the kind of thing that quietly blocks other refactors.

src/format.rs holds the table and three functions over it: the lowercased extension of a path, the libgpod name for an extension, and whether a file is playable at all. Settings::file_type now looks up what the encoder produces instead of restating it, so the libgpod strings are written exactly once. transcode::accepted reads the new module rather than copy::is_playable, which is what breaks the cycle.

Two small things fell out. is_playable did not survive the move in its original form — it had one non-test caller, in the module the copy engine depends on, so it is now a thin call over libgpod_name rather than its own scan of the table. And transcode's private extension helper became a one-line alias for the shared one once the table moved, so it is gone and its three callers name the shared function directly.

No behaviour change; the existing tests pass untouched. The new module carries one test asserting that playability and the libgpod name agree, which is the invariant that having two tables used to risk. 65 unit tests pass, cargo clippy --all-targets clean.

Closes #9.

One module owns what the iPod can play — the extensions, and the names libgpod uses for them. Copying and transcoding both read from it, and neither reaches into the other. Before this, the two split format policy and depended on each other in both directions: the transcoder called into the copy engine to ask whether a file was playable, while separately restating the same libgpod format strings the copy engine's table already held. Adding a format meant editing two tables that had to agree, and the module cycle is the kind of thing that quietly blocks other refactors. `src/format.rs` holds the table and three functions over it: the lowercased extension of a path, the libgpod name for an extension, and whether a file is playable at all. `Settings::file_type` now looks up what the encoder produces instead of restating it, so the libgpod strings are written exactly once. `transcode::accepted` reads the new module rather than `copy::is_playable`, which is what breaks the cycle. Two small things fell out. `is_playable` did not survive the move in its original form — it had one non-test caller, in the module the copy engine depends on, so it is now a thin call over `libgpod_name` rather than its own scan of the table. And `transcode`'s private `extension` helper became a one-line alias for the shared one once the table moved, so it is gone and its three callers name the shared function directly. No behaviour change; the existing tests pass untouched. The new module carries one test asserting that playability and the libgpod name agree, which is the invariant that having two tables used to risk. 65 unit tests pass, `cargo clippy --all-targets` clean. Closes #9.
Copying and transcoding each held half of the format policy and depended
on each other in both directions, so adding a format meant editing two
tables that had to agree.

Closes #9.
wokoman deleted branch refactor/one-format-owner 2026-08-28 20:04:38 +02:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
wokoman/ironpod!16
No description provided.