@hustbaer
Insbesondere der letzte Punkt in deiner Aufzählung hat mich bereits zuvor stark beschäftigt. Wer stellt den Functor/das Callback bereit? Das ist die eigentlich essentielle Frage, die dieses Konstrukt kompliziert macht, weshalb ich es mittlerweise verworfen habe.
Der Hintergrund ist:
Ich bekomme ein vollständiges Konfigurationsobjekt geliefert, welches gewissermaßen für meine Applikation eine Liste von Datenquellen enthält, also eine Art Verbindungsstruktur.
Eine Liste von Services ( Service 'A', Service 'B', etc. ). Jeder Service enthält eine Liste von Partitionen von denen jede unterschiedliche Daten enthält. Jede Partition wiederum hat 1 bis N Connections ( Stichwort Failover ), die aber jeweils identische Daten liefern.
D.h. ich muss im Grunde einen Baum abbilden, der aber dynamisch sein kann, was bedeutet, dass ich jederzeit für jeden Service ein Update bekommen kann, das mich dazu zwingt, die exisiterenden Connections zu trennen und neue aufzubauen. Diese Veränderungen wollte ich einem allgemeinen Container abbilden. Die Services wären dann in so einem Container und in jedem Service bestünde ein weiterer Container, der wiederum die Partitionen enthält. Jedes neue Konfigurationsobjekt würde dann durchgereicht in den Baum bis ganz hinten und die Änderungen in den Daten würden einen Aufruf des Callbacks erzeugen, mit dem Hintergrund, dass auch eine Änderung im hinteren Teil des Baums ( z.B. auf Connectionebene ) einen Callback nach ganz außen zur Folge hätte.
Ich habe aber den Gedanken eines allgemeinen Templates für Speicherung und Abgleich der Configs verworfen, weil gerade die innern Callbacks irgendwo gespeichert werden müssten, oder ich eben stets in jedem Aufruf von "update" eine gewissen Anzahl an Callbacks mitschleppen müsste.