rationale for IAtom2 ?

[dimitris]

Hi all,

This is mainly a question for the Clojure core dev team. I'm trying really hard to understand the thinking behind the new IAtom2 interface. My train of thought is detailed below, but you don't have to read the full thing. The core question is "How come the existing IAtom didn't grow, given the fact that you guys *own* the interface?"

OK so here is the full story:

I recently found out about https://dev.clojure.org/jira/browse/CLJ-1454, and it's true that often you want a version of `swap!` that returns the value that was swapped *out*. As indicated on the ticket various people have worked around the lack of such a fn in various ways. The solution that I'm using/maintaining looks very much like the approach taken with IAtom2, only it's goes through a protocol and it's written in clojure. Basically I've defined a new abstraction and extending it to Atom.

(defprotocol IAtomic
  ... ;; more methods
  (trade!
    [this f]
    [this f x]
    [this f x y]
    [this f x y more]
    "Like `clojure.core/swap!`, but returns the value that was swapped out."))

(defmacro ^:private trade*
  [ref f & args]
  `(let [validate# (.getValidator ~ref)] ;; extract the validator-fn once
     (loop []
       (let [oldv# (.deref ~ref)
             newv# (~f oldv# ~@args)]
         (try
           (when-not (validate# newv#)
             (throw (IllegalStateException. "Invalid reference state")))
           (catch Exception e#
             (IllegalStateException. "Invalid reference state" ) e#))

         (if (.compareAndSet ~ref oldv# newv#)
           (do (.notifyWatches ~ref oldv# newv#)
               oldv#)
           (recur))))))

(extend-protocol IAtomic
  ... ;; more types

  Atom
  (trade!
    ([this f]
     (trade* this f))
    ([this f x]
     (trade* this f x))
    ([this f x y]
     (trade* this f x y))
    ([this f x y more]
     (trade* this #(apply f % x y more)))
    )
)

Ok, so at this point I want to stress out that the way I see it this solution seems to me like the second best option. I say 'second', because IMO the best option would be to add `trade!` (or however you want to call it) to the original IAtom.java and implement it straight in Atom.java. But obviously I can't do that - only clojure.core can. Since clojure.core didn't, I'd say that it's safe to assume that either a) growing IAtom is not desirable, and/or b) having IAtom2 is a superior solution . Personally, I wouldn't be able to explain/defend any of those in a conversation. I'm probably missing something here, and that's exactly why I'm sending this email. Enlighten me please... :) what am i missing? How come IAtom was, in some sense, cloned, rather than grown? Many thanks in advance...

Jim

 ps: oh and btw congrats on the 1.9 release :)

[Andy Fingerhut]

I believe the short answer is: There are existing implementers of the IAtom interface out there.  If the interface grew, those implementers would become broken with Clojure 1.9.0.

There is no deep discussion of the details here, but a mention of wanting to avoid breaking changes in the IAtom interface here: https://groups.google.com/forum/#!searchin/clojure-dev/iatom%7Csort:date/clojure-dev/_ixXNiIyiuQ/p1HrCRGJDAAJ

Andy

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+unsubscribe@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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex Miller]

On Sunday, December 17, 2017 at 4:17:00 PM UTC-6, Jim foo.bar wrote:

Hi all,

This is mainly a question for the Clojure core dev team. I'm trying really hard to understand the thinking behind the new IAtom2 interface. My train of thought is detailed below, but you don't have to read the full thing. The core question is "How come the existing IAtom didn't grow, given the fact that you guys *own* the interface?"

Many of the Clojure interfaces are also implemented by external libraries (IAtom is known to be one of these). Adding new methods to an interface breaks existing implementors. The proper way to "grow" here was to add a new interface which external implementors can extend to when they are ready. This allows all existing implementations continue to work if they compile against Clojure 1.9.

 

[Alex Miller]

I guess I should also mention Rich’s conj keynote from last year where he talks in depth about growing, not breaking, software:

https://m.youtube.com/watch?v=oyLBGkS5ICk