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

Reply via email to