Analyzer::Zig::Zap
Inherits Analyzer < FileHelper < Reference < Object
zap exposes routes two ways:
- Endpoint structs — a struct (often the whole file via
pub const X = @This();) carrying apathslug and one verb method per supported HTTP method (pub fn get/post/put/delete/patch/options/ head). The slug is usually bound where the endpoint is instantiated (X.init("/users", …),.{ .path = "/stop" }), not inside the struct, so paths are resolved project-wide and keyed by struct type. zap.Router—router.handle_func("/p", &inst, &T.method)androuter.handle_func_unbound("/p", handler)map a path to a handler for any method.
Constants
Modern zap.Endpoint.init(.{ .path = …, .get = handler, … }) API: the
supported HTTP methods are declared as option fields bound to handler
functions, instead of as pub fn get/… verb methods on the struct. The
path field is usually a parameter resolved at the T.init("/p", …) call
site, so it is reused through the same bindings machinery.
. is intentionally NOT in the lookbehind: endpoint types are commonly
reached through a namespace re-export (Endpoints.UserWeb.init("/u")),
and the meaningful key is the final segment (UserWeb), which is itself
preceded by a ..
Cheap path-binding gate: one precompiled Regex.union scan (PCRE2 JIT)
in place of two naive String#includes? char scans. Equivalent to
includes?(".path") || includes?(".init(").
Class methods
Instance methods
Instance-side view of the same declaration. The per-file rescues live on
this base class, which has no way to name the analyzer that is running
inside them, so a skipped file could not be attributed to a tech.
Deriving it from analyzer_for keeps the name written exactly once.