Krukow wrote: > Sina K. Heshmati wrote: > [snip] >> The only member data _I'm_ able find are the ones that are passed to the >> default >> constructor, namely at the time that the abstraction is reified. What if I'd >> have >> to give create a member field that is not necessarily known by the caller or >> instantiator. That is, it's the abstraction itself that has to create and >> maintain the value of that field. > > You mean something like a private field in Java that is not supplied > as a constructor argument, but computed as a function of the other > fields, and which is not necessarily accessible from callers. If I > understand correctly what it is you want, I think you are moving away > from Clojure, trying to somehow encapsulate an "object". See RH's note > on encapsulation: "Encapsulation of information is folly. Fields are > public. Use protocols/interfaces to avoid dependencies" [1].
I chose Clojure to experiment with new things rather than applying my old tricks so I'm definitely not looking for encapsulation per se but I should be able to map the concepts from one language to the other in order to be able to effectively code. That said, I'd rather make sure that my low-level data structures are being operated on by only one implementation. The fact that a certain field is immutable reassures me that other programs can't alter it and this is good enough. If I want my abstraction to be able to alter its own state, then I'd use Refs, Atoms, and the like. I hope this is Clojure idiomatic. My implementation of the pair abstraction in Clojure is here: http://github.com/sindoc/algorithms/blob/master/src/main/clojure/memory-management/manual/pairs/pair.clj Right now, external programs can access my low-level data structures e.g. car-mem and alter them since they're 'refs'. This is not good to my eyes, unless someone says: no matter what you do, external programs can still find a way to access the private fields of my implementation e.g. using reflection. Macros could also be used to generate most of the helper functions for car-mem, cdr-mem and next-free. Please feel free to report any bad practices or improvements. >> One of the abstraction that I was hoping to implement in Clojure is a >> Scheme-like >> pair in order to demonstrate various memory management techniques. Once we do >> (cons a b), an abstract pair should be made that only contains a pointer to >> its >> location in memory: (tag address). Here's the pair implementation [2] in >> Scheme >> R5RS. >> > > So you want a mutable pair (fst, snd) where fst and snd can be mutated > arbitrarily? This is definately not the Clojure way :) In Clojure, > you'd either use a pair of atoms or refs, giving you managed > mutability, or you'd simply write a functional pair. Obviously, this is not the Clojure way but I have to simulate the Scheme pair system. Thanks for the follow-up, Krukow. 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
