Hallo 1unitedpower, es ist schon spannend, welche Minimalkonstrukte herauskommen können wenn man eine Weile am Code herumfaktoriert 😀 Durch das Entfernen des Arraytests wird natürlich alles einfacher, der sollte ja auch vor allem vor einer "Fehlbedienung" schützen. Vor allem verlangt dein Code einen weiteren Abstraktionsschritt vom Leser. Die Funktion "isIncludedIn" ist ja nicht der Callback, sondern generiert den erforderlichen Callback. Natürlich liest sich `genresToFind.every(isIncludedIn(movie.genres))` sehr flüssig. Aber man muss dabei im Hinterkopf haben, dass every einen Callback erwartet und isIncludedIn diesen liefert - und nicht selbst der Callback ist. Für eingefleischte funktionale Programmierer mag das eine ganz natürliche Vorgehensweise sein. Ich musste erstmal einen Moment nachdenken, was denn da nun eigentlich passiert. Und dabei habe ich das Konstrukt ja selbst angezettelt. Mein Stolperstein war tatsächlich der Funktionsname. Er suggeriert ein anderes Verhalten, als die Funktion tatsächlich zeigt. Vom Laufzeitverhalten dürften dein und mein Ansatz gleich sein. Es sei denn, dass der Umstand schädlich ist, dass Du pro Movie eine neue Closure erzeugst - ich tue das nicht. Ich erzeuge nur einmal zu Beginn eine. Nicht, dass ich gerade die bessere Idee hätte. Aber hast Du noch eine Idee, die Factory-Charakteristik von isIncludedIn besser im Namen darzustellen? Und eigentlich müsste man es auch noch so bauen, dass der Suchalgorithmus nicht wissen muss, dass er in den durchsuchten Objekten die Matches im genres Property findet, das müsste man injizieren. Und es muss irgendwie ge-namespace-d sein, denn Funktionen wie all und some sind viel zu generisch um sie im globalen Namespace rumfliegen zu lassen. Vielleicht doch besser eine Klasse mit einem fluid interface? ~~~js new TopicSearcher() .search(movie => movie.genres) .forAll("Horror", "Komödie") // oder: .forAny("Foo", "Bar") .in(movies) ~~~ search, all, any und in sind Methoden des von new TopicSearcher erzeugten Objekts. Mit search, forAll und forAny konfiguriert man die Suche, und `in` führt sie durch. Sehr gewöhnungsbedürftig beim ersten Anblick, aber ich mag sowas. Ich finde, für den **Nutzer** liest sich das wie ein Satz. Um es zu bauen, braucht man etwas mehr Schmalz. Letztlich passiert aber nicht viel anderes als bei den oben diskutierten Closures. Und ja, man könnte statt dessen auch einfach zwei Funktionen schreiben, die ohne Objekte das Gleiche tun. Aber hey, es ist 2021 und nicht 1971 😂 _Rolf_ -- sumpsi - posui - obstruxi

Hallo 1unitedpower, es ist schon spannend, welche Minimalkonstrukte herauskommen können wenn man eine Weile am Code herumfaktoriert 😀 Durch das Entfernen des Arraytests wird natürlich alles einfacher, der sollte ja auch vor allem vor einer "Fehlbedienung" schützen. Vor allem verlangt dein Code einen weiteren Abstraktionsschritt vom Leser. Die Funktion "isIncludedIn" ist ja nicht der Callback, sondern generiert den erforderlichen Callback. Natürlich liest sich `genresToFind.every(isIncludedIn(movie.genres))` sehr flüssig. Aber man muss dabei im Hinterkopf haben, dass every einen Callback erwartet und isIncludedIn diesen liefert - und nicht selbst der Callback ist. Für eingefleischte funktionale Programmierer mag das eine ganz natürliche Vorgehensweise sein. Ich musste erstmal einen Moment nachdenken, was denn da nun eigentlich passiert. Und dabei habe ich das Konstrukt ja selbst angezettelt. Mein Stolperstein war tatsächlich der Funktionsname. Er suggeriert ein anderes Verhalten, als die Funktion tatsächlich zeigt. Vom Laufzeitverhalten dürften dein und mein Ansatz gleich sein. Es sei denn, dass der Umstand schädlich ist, dass Du pro Movie eine neue Closure erzeugst - ich tue das nicht. Ich erzeuge nur einmal zu Beginn eine. Nicht, dass ich gerade die bessere Idee hätte. Aber hast Du noch eine Idee, die Factory-Charakteristik von isIncludedIn besser im Namen darzustellen? _Rolf_ -- sumpsi - posui - obstruxi