I'm not sure whether this is a good idea, but it's something I've talked about and mentioned sometimes.
Currently, the Vole "constraints" functions immediately give you one refiner that refines for your constraint. But perhaps this is not always optimal: perhaps for some search instances, it would be better if the constraint was converted into a refiner differently, or maybe even converted into multiple refiners.
A use case could be normalisers: there may be refiners for normalisers that have clever tricks that don't work in 'canonical' searches. Therefore it would be nice for the normaliser constraint to translate in non-canonical searches into refiners that do these clever tricks, but for canonical searches, the normaliser constraint would be translated into canonical-safe refiners.
This could tie in with #25; where a refiner could know what constraint it was implemented for, and constraints would share some (many?) of the properties/attributes that I propose for refiners.
wilfwilson
commented
2 years ago
I'm not sure whether this is a good idea, but it's something I've talked about and mentioned sometimes.
Currently, the Vole "constraints" functions immediately give you one refiner that refines for your constraint. But perhaps this is not always optimal: perhaps for some search instances, it would be better if the constraint was converted into a refiner differently, or maybe even converted into multiple refiners.
A use case could be normalisers: there may be refiners for normalisers that have clever tricks that don't work in 'canonical' searches. Therefore it would be nice for the normaliser constraint to translate in non-canonical searches into refiners that do these clever tricks, but for canonical searches, the normaliser constraint would be translated into canonical-safe refiners.
This could tie in with #25; where a refiner could know what constraint it was implemented for, and constraints would share some (many?) of the properties/attributes that I propose for refiners.