[nathanhammond]

Thinking about it more, I believe that my visceral reaction was to the imperative nature of the library. I was imagining trying to code something that generated a filter (e.g. PourOver.makeExactFilter("mythology", ["greek","norse"]);) and it seems like it would be unnecessarily complex without data-binding propagation/invalidation.

If I wanted to add "roman" mythology to that filter I would imagine something like:

    var mythologies = ["greek", "norse"];
    // ... create a collection with filters
    mythologies.push("roman");
    PourOver.makeExactFilter("mythology", mythologies);

But you don't get that last statement for free, nor the one where you join it into a collection, nor do I see a way to replace the previous mythologies filter. Any time you need to reprocess a filter you've got to run it through a series of imperative actions triggered from one of the events, and possibly throw away the collection and regenerate it (if you can't remove disjoint filters).

I would be pushing for a Object.observe/dirty checking/get-set version of this to take PourOver to the next level of utility. (?/Angular/Ember)

[esmooov]

I think I'm a little confused. Why wouldn't you have just added the "roman" possibility from the get go? Could you provide an example of a situation when you don't know the universe of possibilities in advance?

[rattray]

If the user adds one, or new data enters from an outside source (pub/sub, sockets, etc)

[esmooov]

Alright, this is a great point. It would be trivial for me to add addPossibilities. I think I'll do that! Thanks. This will really help for using PourOver to power tagging selection fields where you can ... add possibilities!

[nathanhammond]

Exactly what @rattray said. It's something you get nearly for free in data-binding world and is much harder to accomplish in imperative code. I wish you luck, and make sure you blog about it when it's done! (I want to see how it's implemented.)