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. 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))))
; 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*)))
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?
Sincerely
Meikel
--
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
