Change NewChecker to take a Params struct instead of positional arguments #78
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Context
The Go style guide: "Constructors must take a
Paramsstruct... evenfor a single argument... Positional arguments for constructors are an
endless source of bugs."
mfer/checker.go:88:Three positional arguments, the first two of which are same-typed
stringsthat are easy to transpose and impossible for the compiler to catch. This is
precisely the failure mode the rule exists to prevent, and it is on a
constructor that is part of the library's public API — so it must be fixed
before 1.0 freezes it.
mfer/scanner.go:86already does this correctly:func NewScannerWithOptions(opts *ScannerOptions) *Scanner. The codebase isinternally inconsistent.
Definition of done
NewCheckertakes a params struct with named fields for the manifestpath, base path, and filesystem.
ScannerOptionsconvention in the same package — do not introduce a second naming style
for the same concept.
when the filesystem field is nil (default to the OS filesystem, or error),
and what happens when a required path is empty (error, with a clear
message).
make checkpasses.TODO.mdupdated in the same commit.Implementation requirements
should happen. Do not add a compatibility shim or keep the old positional
constructor alongside the new one — that would preserve the bug class into
1.0.
mferpackage for the same violation and fix them in the same PR. A partial
migration is worse than none because it leaves the convention ambiguous.
List what you found and what you changed in the commit message.
Checker's behavior. This is a signature change only; anybehavior difference is a bug in the change.
sites to use positional struct literals, which reintroduces exactly the
ordering hazard being removed.
(closes #78).