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 [reference (SoftReference. x)
obj (SoftRefHolder reference)]
obj))
It works great, and I haven't encountered any problems yet. My
interpretation of the clojure source code is that Rich intentionally
made "things that can be dereferenced" (IDeref) orthogonal to "things
that participate in clojure concurrency" (IRef / Atom / Agent)
My one concern about fetching the session map from a database is the
cost in time. All the other deref operations take about as much time
as grabbing a lock. Going to the DB is an order of magnitude longer.
Typically, I use the session data multiple times per request. Maybe if
it were cached / memoized, that would be better.
Allen
On Feb 7, 3:12 pm, James Reeves <[email protected]> wrote:
> On Feb 7, 4:06 pm, Laurent PETIT <[email protected]> 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 be more general. For
> instance, derefing a session object might fetch the corresponding
> session map from a SQL database.
>
> The alternative would be to write some deref-like function with a
> different name. However, I'm wondering if deref is currently generic
> enough that it could be used instead.
>
> - James
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
