Skip to content

RecognitionMethod constructor style consolidation #215

Description

@martsokha

RecognitionMethod exposes seven ad-hoc associated constructors on the enum (regex, regex_validated, dictionary, deny_list, cross_reference, nlp_ner, llm_ner, annotation) alongside the per-struct ctors on the inner provenance types (ModelProvenance::new, PatternProvenance::Regex { … } literal, etc).

Problem

Three overlapping ways to build the same value:

  1. Enum factory: RecognitionMethod::regex("ssn")
  2. Inner-ctor + wrap: RecognitionMethod::Pattern(PatternProvenance::Regex { name: "ssn".into(), validator: None, contextual: false })
  3. Builder pattern (where present): not currently used here but the rest of the ontology uses derive_builder

Producers reach for whichever the call site happens to land on, and validator / contextual are positional arguments in the factories but named fields in the literals.

Options

  • One style for everything. Pick either the enum factories (simpler call sites) or the struct literals (no need to invent new helpers for each variant combo) and migrate.
  • Tier it. Keep enum factories for the common case (zero-config regex / dictionary / deny_list) and require struct literals for anything that wants validator or other knobs.

Cost

Probably 30 min if the answer is obvious from a 10-minute pass through the producers. File and revisit if it isn't.

Found during the nvisy-ontology polish pass (audit item 12.2).

Metadata

Metadata

Assignees

No one assigned

    Labels

    ontologyentities, policies, contextsrefactorcode restructuring without behavior change

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions