Problem solved, see below. Meikel Brandmeyer wrote: > On May 31, 1:46 pm, "Sina K. Heshmati" <s...@khakbaz.com> wrote: > >> Here's my concern: >> >> - My program (A) is running. >> - B is running on the same VM. >> - B accesses the state of A. >> - B alters the state of A in an inconsistent way >> e.g. whenever the internal state x changes, the >> internal state y also has to change accordingly, >> but B only changes x. >> - A is screwed. > > A is namespace my.ns.a. There you define a private var: (def > ^{:private true} state (atom 0)). B is namespace my.ns.b. B cannot > change state in A. > > user=> (ns my.ns.a) > nil > my.ns.a=> (def ^{:private true} state (atom 0)) > #'my.ns.a/state > my.ns.a=> (ns my.ns.b) > nil > my.ns.b=> (reset! my.ns.a/state :messed-up-your-state-harharhar) > java.lang.IllegalStateException: var: my.ns.a/state is not public > (NO_SOURCE_FILE:4) > > From a philosophical point of view: > Either you develop an application and > you are in charge of B. => You are in control: don't do it. > you are not in charge of B. => B is obviously a crappy library which > you should not use in project. > > You develop a library: A. Why bother? Since your library is well > documented it clearly defines the contract. Why care for people who > are too lazy to read?
True but my main concern is security of a running application. It could very well be that B is just a bunch of interactions, in which case B can enter A's namespace. I still haven't tried to use reflection to see if I can still access the state. In case a program can use metaprogramming to access private fields of an abstraction, no matter what the programmer does, then my concerns are not relevant. >> Is there a way to pass the function itself rather >> than making a new function that calls the exact >> same function with the same arguments? > > (let [state (atom 0)] > (extend t-a > prot-a > {:op-a (fn [this x y] (+ (.member this) x y @state))})) Thanks a bunch, Meikel. Problem solved. Please see: http://github.com/sindoc/algorithms/blob/master/src/main/clojure/whiteboard/y2010/hide-adt-state/datatype-and-closure-01.clj Kind regards, SinDoc -- 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