Decide: trim the iPod wrapper interface to what is called? #11

New issue

Open

opened 2026-08-25 22:30:06 +02:00 by wokoman · 0 comments

wokoman commented

2026-08-25 22:30:06 +02:00

(Migrated from code.nolog.cz)

What to explore

Whether the FFI wrapper's interface should shrink to what the codebase actually calls.

Fourteen of the track type's sixteen getters are one-line field reads, and a good share of the surface has no caller at all — the album artist, composer, disc number and sample-rate getters, a path setter, most of the playlist module, and an error variant that is never constructed. One method returns a fallible result from a body that cannot fail.

The argument for deleting it: what remains is the part that earns its keep — the string-field handling with its free-then-duplicate dance, the ownership flag, the deliberate non-thread-safety — and the module gets deeper by losing surface. Less unsafe code to audit. The deletion test says it concentrates rather than scatters. Entirely reversible.

The argument against, and the reason this is speculative: an FFI wrapper is a reasonable place to mirror the C struct once and then stop thinking about it. Deleting getters today means writing them again the first time a feature needs one, and the roadmap has features that plausibly will — playlist editing is the obvious one, and most of the playlist module is on the unused list.

What would settle it

Whether the unused surface is actually costing anything. It is the kind of code an agent reads past on every visit to the module, which is a real cost even when a human's editor folds it away. Weigh that against the roadmap: if playlist editing is coming, deleting the playlist module now is churn.

What "done" looks like for this ticket

A decision, and if it is "leave it", a recorded finding so a future architecture review does not raise it again.

Blocked by

None — but this is a decision, not a task. Do not delete anything before the decision is made.

## What to explore Whether the FFI wrapper's interface should shrink to what the codebase actually calls. Fourteen of the track type's sixteen getters are one-line field reads, and a good share of the surface has no caller at all — the album artist, composer, disc number and sample-rate getters, a path setter, most of the playlist module, and an error variant that is never constructed. One method returns a fallible result from a body that cannot fail. The argument for deleting it: what remains is the part that earns its keep — the string-field handling with its free-then-duplicate dance, the ownership flag, the deliberate non-thread-safety — and the module gets deeper by losing surface. Less unsafe code to audit. The deletion test says it concentrates rather than scatters. Entirely reversible. The argument against, and the reason this is speculative: an FFI wrapper is a reasonable place to mirror the C struct once and then stop thinking about it. Deleting getters today means writing them again the first time a feature needs one, and the roadmap has features that plausibly will — playlist editing is the obvious one, and most of the playlist module is on the unused list. ## What would settle it Whether the unused surface is actually costing anything. It is the kind of code an agent reads past on every visit to the module, which is a real cost even when a human's editor folds it away. Weigh that against the roadmap: if playlist editing is coming, deleting the playlist module now is churn. ## What "done" looks like for this ticket A decision, and if it is "leave it", a recorded finding so a future architecture review does not raise it again. ## Blocked by - None — but this is a decision, not a task. Do not delete anything before the decision is made.