Re: Inheriting from IDeref - good idea or bad practise?

2010-02-08 Thread Jarkko Oranen
On Feb 8, 3:22 am, Stuart Halloway stuart.hallo...@gmail.com wrote: IMO Anything that implements IDeref should adhere to Clojure's vision   for identity, e.g. reads need to be thread safe, cheap, require no   coordination, and block no one. Dereferencing futures or undelivered promises block

Re: Inheriting from IDeref - good idea or bad practise?

2010-02-08 Thread Steven E. Harris
James Reeves weavejes...@googlemail.com writes: Would those more knowledgable about Clojure care to weigh in on whether it be a good idea to create a custom class inheriting from IDeref? That's how promise is implemented, but that's supposed to be an internal detail. -- Steven E. Harris --

Re: Inheriting from IDeref - good idea or bad practise?

2010-02-08 Thread Sean Devlin
I've got no clue, so I would just do the experiment. If it works out well, tell us why. If it's a disaster, tell us what didn't work. Sean On Feb 7, 3:57 pm, James Reeves weavejes...@googlemail.com wrote: Hi folks, Would those more knowledgable about Clojure care to weigh in on whether it

Inheriting from IDeref - good idea or bad practise?

2010-02-07 Thread James Reeves
Hi folks, Would those more knowledgable about Clojure care to weigh in on whether it be a good idea to create a custom class inheriting from IDeref? I've been considering creating session proxy objects (to be later replaced with protocols) that would respond to deref calls, e.g. (def session

Re: Inheriting from IDeref - good idea or bad practise?

2010-02-07 Thread Laurent PETIT
I don't know, but it seems like a bad smell that you can't find your joy by using the built-in state management constructs ( a bad smell in general, not saying on your side or on clojure side ) 2010/2/7 James Reeves weavejes...@googlemail.com: Hi folks, Would those more knowledgable about

Re: Inheriting from IDeref - good idea or bad practise?

2010-02-07 Thread James Reeves
On Feb 7, 4:06 pm, Laurent PETIT laurent.pe...@gmail.com wrote: I don't know, but it seems like a bad smell that you can't find your joy by using the built-in state management constructs The build-in state management constructs only deal with data in memory. I'm thinking deref could potentially

Re: Inheriting from IDeref - good idea or bad practise?

2010-02-07 Thread Allen Rohner
I can't comment on style, but I can say I successfully made a protocol to implement SoftReferences: (deftype SoftRefHolder [#^java.lang.ref.Reference ref] clojure.lang.IDeref (deref [] (.get ref))) (defn soft-reference returns a soft reference to x. Access using deref [x] (let

Re: Inheriting from IDeref - good idea or bad practise?

2010-02-07 Thread Stuart Halloway
IMO Anything that implements IDeref should adhere to Clojure's vision for identity, e.g. reads need to be thread safe, cheap, require no coordination, and block no one. Stu Hi folks, Would those more knowledgable about Clojure care to weigh in on whether it be a good idea to create a