SymbolSource and SymbolBackend both declare childrenOf(NamespaceName): NamespaceContents and search(string, NameKind): list<Symbol> with identical signatures. CompositeSymbolSource implements the former by delegating to the latter, so the duplication is structural — the facade repeats what the backend already defines.
The lookup methods avoid this because SymbolSource splits them per-kind (lookupClassLike, lookupFunction, lookupConstant) while SymbolBackend unifies them as lookup(name, kind). That asymmetry is the design intent; the shared methods are the ones where the facade adds no narrowing.
This likely resolves naturally as the M×N collapse progresses — the build manifest steps are already reshaping both interfaces. If it persists after the baselines are deleted, it deserves a targeted fix (e.g. extracting the shared surface into a parent interface, or having SymbolSource extend SymbolBackend).
This issue was written by AI and reviewed by a human.
SymbolSourceandSymbolBackendboth declarechildrenOf(NamespaceName): NamespaceContentsandsearch(string, NameKind): list<Symbol>with identical signatures.CompositeSymbolSourceimplements the former by delegating to the latter, so the duplication is structural — the facade repeats what the backend already defines.The lookup methods avoid this because
SymbolSourcesplits them per-kind (lookupClassLike,lookupFunction,lookupConstant) whileSymbolBackendunifies them aslookup(name, kind). That asymmetry is the design intent; the shared methods are the ones where the facade adds no narrowing.This likely resolves naturally as the M×N collapse progresses — the build manifest steps are already reshaping both interfaces. If it persists after the baselines are deleted, it deserves a targeted fix (e.g. extracting the shared surface into a parent interface, or having
SymbolSourceextendSymbolBackend).This issue was written by AI and reviewed by a human.