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
