I'm arguing that IMHO, the atom+watcher abstraction is not rich enough to build upon.
Atoms have the watcher list natively built into their datastructure. But the watcher abstraction is too simple to do anything beyond syntactic sugar. If you want to roll your own, you need to maintain your own notification system and bypass the existing mechanism entirely. This is what I'll end up doing. Though if the update action had an additional parameter, it would be more flexible. Out of curiosity, what do you do with the old value? On Thu, Feb 16, 2012 at 8:15 AM, David Nolen <dnolen.li...@gmail.com> wrote: > Sounds like you should build a simple abstraction layer over atoms instead > of trying to use them directly? Or provide a new data binding / propagation > protocol that avoids the limitation of atoms? For data binding you most > definitely always want to receive the old value in my experience. > > > On Wednesday, February 15, 2012, kovas boguta <kovas.bog...@gmail.com> > wrote: >> More than a few people have noticed the similarities between >> add-watch, and event/data binding in things like Backbone.js. >> >> Maybe its worth considering if a feature marked as "alpha" is really >> the best thing for this case. >> >> 1. add-watch arguments are verbose. Do we really need a key to name >> the watcher, and the old value? For the vast majority of cases, no. >> >> 2. cascading changes is verbose. Often you want the watcher to update >> another atom, but all this needs to be set up manually. >> Perhaps something simpler like >> (echo f some-atom) >> could return a new atom, whose value is (f some-atom) and is updated >> with each change. >> >> 3. Incremental updates are difficult; the action performed on the >> source atom is opaque >> Simply being informed of values is not enough -- if you know what >> action was performed on the source atom, you can proceed more >> efficiently. Instead of recomputing an entire sequence of dom >> elements, you could insert/delete the relevant ones, or decide which >> other actions need to be taken. >> >> This last problem could potentially be addressed by adding meta-data >> to the update action, which is then propagated to the watchers. >> >> Another approach would be to introduce new reference types >> corresponding to clojure collections, atom-vector and atom-map, which >> could incrementally update themselves from the source atom. >> >> Something like >> >> (echo f (atom-vector X)), >> >> where atom-vector implements a protocol allowing for incremental >> updates which then get propagated to echo'ing atom. >> >> Figuring out a reasonable way to deal with collections is a big >> stumbling block for me, in trying to build data-binding abstractions >> in clojurescript. Recomputing everything is suboptimal (though it is >> also suboptimal that there is no data sharing in the current >> implementation of the clojurescript collections so you end up copying >> everything on each modification anyway) >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
