[jasperfx] Additive IEventRegistry generic DIMs: AddEventType<T>() and EventMappingFor<T>() (P3.2a)

[jeremydmiller]

Part of #5110. Target repo: JasperFx/jasperfx (tracked here per program convention; the actual PR lands there and rides a routine version bump into Marten and Polecat).

Add default interface methods to JasperFx.Events.IEventRegistry (src/JasperFx.Events/IEventRegistry.cs):

void AddEventType<T>() => AddEventType(typeof(T));
IEventType EventMappingFor<T>() => EventMappingFor(typeof(T));

Why: today only the non-generic forms are shared. Marten's EventMappingFor<T>() is internal (reachable only via InternalsVisibleTo — the compliance library has a zero-IVT rule) and returns EventMapping; Polecat's public override takes Type and returns PolecatEventType. Both concrete types implement IEventType, so the DIM unifies the assertion surface (.EventTypeName) for all test code in both repos, not just the compliance suites.

Non-breaking: DIMs only; existing store-specific members are unaffected (Marten's internal generic can later be retired independently).

Sequencing: not a hard blocker for P3.1 (the seam can call the Type-based forms), but landing it before P3.3 extraction lets the shared sources use the generic forms directly.

🤖 Generated with Claude Code

[jeremydmiller]

Investigated while building the seam (#5111). The DIMs as specified cannot land without breaking Marten, and the compliance library does not need them.

Both proposed default interface methods collide with existing EventGraph members that have incompatible return types, so adding them to IEventRegistry is a compile error in Marten (CS0738), not a silent no-op:

Proposed DIM	Colliding Marten member
void AddEventType<T>()	public IEventStoreOptions AddEventType<TEvent>() (src/Marten/Events/EventGraph.cs:383) — returns the options for fluent chaining, and that signature is itself the result of walking back a source-breaking change in #4917
IEventType EventMappingFor<T>()	internal EventMapping EventMappingFor<T>() where T : class (src/Marten/Events/EventGraph.cs:728) — different return type and a tighter constraint

Making room for the DIMs means changing AddEventType<T>()’s public return type, which is a source-breaking change for every caller that chains off it, including our own docs samples. Not worth it for ergonomics.

Meanwhile the stated motivation is already handled. The compliance seam asserts event type names through the shared non-generic form and needs zero InternalsVisibleTo:

protected string EventTypeNameFor<T>() => theFixture.Registry.EventMappingFor(typeof(T)).EventTypeName;

Recommend closing as won't fix unless a future JasperFx major wants to converge the fluent shapes. If the generic ergonomics are still wanted, a non-colliding name (IEventType EventTypeFor<T>()) would be additive.

[jeremydmiller]

Closing as not planned, per the investigation above and the Phase 3 wrap-up on #5110.

Short version: the DIMs cannot land as specified without breaking Marten. void AddEventType<T>() collides with EventGraph.AddEventType<TEvent>() (returns IEventStoreOptions for fluent chaining) and IEventType EventMappingFor<T>() collides with the internal EventMapping EventMappingFor<T>() where T : class — both CS0738, incompatible return types. Making room means changing a public return type that callers and docs samples chain off.

The motivation is also gone: the compliance library shipped needing zero InternalsVisibleTo, asserting event type names through the shared non-generic IEventRegistry.EventMappingFor(Type) → IEventType.EventTypeName.

Reopen if a future JasperFx major wants to converge the fluent shapes. If the generic ergonomics are wanted sooner, a non-colliding name (IEventType EventTypeFor<T>()) would be purely additive — worth a fresh issue rather than reviving this one.