After #1962 the extensions in CoreSearchTools.kt are named vectorSearchWithFilter and textSearchWithFilter, identical to the members on FilteringVectorSearch and FilteringTextSearch. The dispatch branch
this is FilteringVectorSearch -> vectorSearchWithFilter(request, clazz, metadataFilter, entityFilter)
relies on Kotlin resolving members ahead of extensions to reach the member rather than recurse into itself. That works today and both paths are covered by tests.
The residual risk is that if either member signature ever drifts, the call silently rebinds to the extension and becomes unbounded recursion at runtime instead of a compile error. Worth either a comment at both sites recording the dependency on member-wins resolution, or a distinct internal name for the extensions.
Separately, the extensions do not carry the = null defaults the interface members declare, so a two-argument call compiles against a FilteringVectorSearch receiver but not against a plain VectorSearch one. Adding the defaults would make the two surfaces uniform.
After #1962 the extensions in
CoreSearchTools.ktare namedvectorSearchWithFilterandtextSearchWithFilter, identical to the members onFilteringVectorSearchandFilteringTextSearch. The dispatch branchrelies on Kotlin resolving members ahead of extensions to reach the member rather than recurse into itself. That works today and both paths are covered by tests.
The residual risk is that if either member signature ever drifts, the call silently rebinds to the extension and becomes unbounded recursion at runtime instead of a compile error. Worth either a comment at both sites recording the dependency on member-wins resolution, or a distinct internal name for the extensions.
Separately, the extensions do not carry the
= nulldefaults the interface members declare, so a two-argument call compiles against aFilteringVectorSearchreceiver but not against a plainVectorSearchone. Adding the defaults would make the two surfaces uniform.