I'd like to discuss this design approach. (It's unrelated to the
testing issue.) I avoided this design because the undo-fn is
determined at do-patch! time. The use case is for a persistent system
like Git where patches may be undone long after being done - e.g. long
after the patch is written to the database. In the meantime, the
system may be upgraded and the undo-fn for a patch may change. If the
undo-fn and args is written to the database at do-patch! time, for
backwards compatibility, at undo-patch! time, the undo-fn would have
to be updated to whatever the new call is.
Contrast that with my current approach where only the fn is saved and
the undo-fn is determined at undo-patch! time. For backwards
compatibility, the undo-fn would have to support legacy fn formats,
which I conjecture are slightly less likely to change than the
corresponding undo-fn. This is a pure guess and is not based on real
requirements yet; I don't know that fns themselves are necessarily
more stable than their counterpart undo-fns. It's a vague sense that
undo-fns are more subject to bug fixes: fns themselves are processed
right away at do-patch! time, while undo-fns are like time bombs that
lay dormant until a patch has to be undone, long after the initial
patch.
In addition, in the current implementation I outlined, the undone
patch disappears. The real implementation will most likely be a patch
with undo-patch! as the :fn and the patch being undone as the :arg.
This is necessary to support merging with remote branches like in
Git. undo-patch!'s may themselves be undone, which would require 2
degrees of backwards compatibility: converting the undo-fn in the
first undo, and converting the fn in the second undo. Both approaches
have the same 2 degrees of backwards compatibility, but the command
approach still somehow seems more fragile.
I'd love to get your thoughts on this. Anyone with experience working
on a similar system?
Thanks!
Alyssa
On Dec 22, 4:35 am, Meikel Brandmeyer <m...@kotka.de> wrote:
> Hi,
>
> maybe a different approach could be to use a richer datatype than a function,
> which carries both: the command and the undo command.
>
> (deftype Command [action undo])
>
> Then you could do something like:
>
> (defn do-patch!
> [command args]
> (dosync
> (let [patch {:command command :args (vec args)}]
> (apply (.action command) args)
> (alter patches- conj patch)
> patch)))
>
> (defn undo-patch!
> []
> (dosync
> ((.undo (:command patch)))
> (alter patches- pop)))
>
> Then you could provide specially crafted Commands and there would not be the
> need to stub anything. Also Commands wouldn't have to be global objects.
>
> 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
