Another idea: we could make SearchPredicateTerminalContext extend SearchPredicate, or completely replace it with SearchPredicate. Essentially, that would mean making the SearchPredicate retrieved from the DSL mutable. But if you think about it, they currently are anyway: nothing stops you from calling methods on the DSL contexts after you retrieved the SearchPredicate, and they will mutate builders that are used by the SearchPredicates. We could solve that internally by “freezing” the DSL contexts upon first use (and we could take this opportunity to get rid of unnecessary references such as the SearchPredicateFactoryContext). One advantage is that even the non-lambda syntax would no longer require the use of .toPredicate(); the obvious downside being that it may not always be clear when the user can use a DSL context as a SearchPredicate. Maybe we should leave the .toPredicate() method, just to guide users through auto-completion? Anyway, I don’t have time to implement this right now, but it’s something to think about… Guillaume Smet Fabio Massimo Ercoli maybe we can talk about it during our next Google Hangout? |