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 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
(proxy [IDeref] []
(deref [this]
(read-session (.store this)))
(store [this]
{:type ::memory-store})))
Is this a good idea, or is it considered bad practice to use IDeref in
anything apart from core Clojure concurrently primitives?
- James
--
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
--
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
