2010/8/5 Meikel Brandmeyer <m...@kotka.de> > Hi, > > On Aug 5, 11:34 am, Laurent PETIT <laurent.pe...@gmail.com> wrote: > > > Now one more question please: your solution looks also slightly more > complex > > from the user's perspective: he has to deal with the *parser* object and > the > > future object (returned by schedule-parse). > > > > So the question is: what does your solution provide that the sketch of my > > solution does not ? Do you see my solution harder to implement ? Do you > see > > your solution more generic ? Smth else ? > > I'm hesitant to extend existing types in a way, so that they behave > slightly different.
not types, but interfaces. But you're right, and there were some java.util.concurrent.Future methods which did not make sense in my first design, so I implemented my own Cancellable protocol, resulting in cleaner semantics. > This ties your program to the API of the type at > hand. If that changes, your program is broken until you update your > code. So I prefer using existing things first. If it doesn't work out, > one can still do a custom thing. > > That said: man! What was I thinking? > > (def *parsed-code* (atom nil)) > > ; First concern: > ; When characters are typed we have to re-parse things. > ; But delay it! > (defn char-typed-hook > [] > (reset! *parsed-code* (delay (parse-code)))) > ok > ; Second concern: > ; Use the parsed information. > ; This will trigger the delayed parsing. > (defn mark-errors > [] > (let [parsed-code (force @*parsed-code*)] > ...)) > > ; Third concern: > ; Parse things AOT in a calm second to provide better user experience. > ; THIS IS A SIDE-EFFECT! You might want to store the future somewhere > ; to be able to cancel it, etc. > (defn cursor-hold-hook > [] > (future > (Thread/sleep trigger-delay) > (force @*parsed-code*))) > > ok. What I don't like with your approach is that the behaviour isn't embedded in a reusable fashion, but must be applied throughout the user codebase, with these (force @) calls. But you proved your point. > Consumers trigger the delay if necessary. In such a case the future > becomes a no-op. The future itself can still be canceled if necessary. > The consumers don't have to care about the future at all. > > Does this make more sense? > > yes, our solutions are quite similar, mine being a bit more encapsulated, but adds this Cancellable protocol. Hmm, in the end, what do you prefer ? -- 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
