Re: Encapsulating Local Mutable State

2016-05-02 Thread Stefan Kamphausen
Good point, Paul. Thanks. Best, stefan -- 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

Re: Encapsulating Local Mutable State

2016-04-27 Thread Paul Mooser
One thing you can do is use 'reify', which will allow you to implement a protocol but also have your state atom hidden in a closure. You'll still be passing an 'object' to all of the protocol methods (obviously), but it won't be the atom itself. -- You received this message because you are

Re: Encapsulating Local Mutable State

2016-04-16 Thread Stefan Kamphausen
Hi Francis, Thanks for taking the time to thoroughly explain your approach. I find it interesting and was not yet aware of it. Need to wrap my head around it a bit. Best, Stefan -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this

Re: Encapsulating Local Mutable State

2016-04-15 Thread Francis Avila
If you can model the authentication process as a state machine, have a pure function which accepts auth-state and data and returns either a new state or an operation to get new data to determine the next state. E.g. (next-auth-state {:stage :not-authed :login "login" :password "pass"} nil) =>

Encapsulating Local Mutable State

2016-04-15 Thread Stefan Kamphausen
Hi, Currently, I am in the process of writing a client to server API which is not trivial to consume. In particular it needs a 3-step authentication process: login with user name and password, get an authentication token, open a session with the token and finally consume the API with the