2010/8/6 Kyle Schaffrick <k...@raidi.us> > On Fri, 6 Aug 2010 00:04:08 +0200 > Laurent PETIT <laurent.pe...@gmail.com> wrote: > > > > No offense, but ... are you serious ? > > So my off-the-cuff, wrote-it-in-5 minutes code is laughable? If you > mean no offense then why say this at all? >
I regret having written this. I was upset by a totally different subject, and should have thought twice before hitting "send". It's not laughable. But it looked scary at first, to be honest. > > :( > > > > > I still prefer my own version, repeated here for the record : > > > > (ns delay.util) > > > > (defprotocol Cancellable (isCancelled [this]) (cancel [this])) > > > > (defn timed-delay [pause fun] > > (let [d (delay (fun)) > > f (future (Thread/sleep pause) @d)] > > (reify > > clojure.lang.IDeref > > (deref [_] @d) > > delay.util.Cancellable > > (isCancelled [_] (future-cancelled? f)) > > (cancel [_] (future-cancel f))))) > > > > -> the deref is on a delay, so it's causing no harm. > > -> the code does not try to do "too much at once" : it only deals > > with one value, letting the client decide if the succession of values > > should be stored in an atom, in a ref, etc. > > > > I can agree it does do a better job of separating the time-delayed > concept from the rest of the problem than what I wrote. > > I suppose I misunderstood what you were asking about, since this > doesn't appear to be the whole solution to the original scenario you > spoke of: your consumer must cancel the old and create a new > timed-delay manually if they wish to supersede the input value (i.e. > whenever the user types something). > Yes, there are 2 types of "consumers" in the code: the one which just want to get the value out of the ref, which will depend on the IDeref interface, and the one which is responsible for updating the holder of the ref, and indeed it's also responsible for calling cancel with my scenario. It's a tradeoff I currently can leave with. Future (no pun intended) will tell whether I was wrong or not :) > > But of course, if this is the contract you need then by all means, it's > certainly much better. (Although, Java's big scary list of caveats and > gotchas surrounding Future.cancel() kinda bother me personally...) > > > Still not perfect for the names, but currently quite satisfied by the > > feature/code lines and feature/code simplicity ratios :-) > > > > Sounds good to me then. > > -Kyle > > -- > 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<clojure%2bunsubscr...@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
