Status: Accepted
Date: 2025-11-20
Author: Walmir Silva
Supersedes: N/A
A flat processor registry (name → processor) forces globally unique names. When a project uses both KaririCode\Validator and KaririCode\Sanitizer, both may register a processor named trim — collision.
ProcessorRegistry uses a two-level map: context → processorName → Processor.
$registry->register('validator', 'trim', new TrimValidator());
$registry->register('sanitizer', 'trim', new TrimSanitizer());
// No collision — different contexts
$validator = $registry->get('validator', 'trim');
$sanitizer = $registry->get('sanitizer', 'trim');Principle 3 (Adaptive Context Awareness):
Context(t) = {metrics(t), conditions(t), history(t)} → Adaptation(t+1)
The processing context determines which domain the processor belongs to. The registry's context parameter is the structural expression of this principle.
Principle 4 (Protocol Agnosticism):
The same processor class can be registered under multiple contexts for different protocol handlers (e.g. http.validator vs grpc.validator).
- Zero naming collisions across domains
- Clean integration between Validator, Sanitizer, Transformer, and Normalizer components
- Context names serve as documentation of intent
- Two strings required per
get()call instead of one - Slightly more verbose API
ProcessorBuilderabstracts the context parameter — end users typically interact with it rather than the registry directly
- Prefixed names (
validator.trim,sanitizer.trim): Rejected — convention-based, no compile-time or runtime enforcement, fragile to typos. - Separate registry instances per context: Rejected — complicates DI configuration and cross-context introspection.
- ARFA 1.3 Specification §4.3 (ProcessorRegistry Type Definition)
- KaririCode Standard Specification V4.0 §5.2 (Context Partitioning)