On Nov 18, 1:49 am, Alex Osborne <a...@meshy.org> wrote:
> Hi Alyssa,
>
> I don't think this situation is possible because Namespace.mapping
> (which maps symbols to vars and classes) is *not* thread-local.  For a
> given namespace and symbol all threads will resolve the same var object.
>
> It's the binding of the Var to a value that can be thread-local.
> You shouldn't have to worry about it, as it happens in the dynamic
> environment when the fn is called, not when it is loaded.

Perfect!  That makes things so much easier!  I assume that interning
vars is synchronized then?  This is the second big source code read
FAIL in two days.  Obviously I can't read.  :)
>
> My preference would probably lean towards (2a).  Anyone using drefs is
> going to have to deal explicitly with the issue of objects that aren't
> serializable (sockets, streams), so make them be very careful about what
> they put in them.

Agreed.  Only immutable objects may be persisted, unless they use one
of the official identities (ref,atom,agent) for mutability.

(2a) makes things easy.  I'll have to play around to see if it's too
restrictive.
>
> For the sake of practicality, I'd probably just be totally draconian
> about it and make fns and vars not durable at all.  Almost any way you
> do it they'd make the program very brittle.  They'd tie using the data
> very tightly to the structure of the source code, meaning that if you
> change the program (say rename a var) you're likely to not be able to
> read the data any more.

All persistence requires dealing with migrations and compatibility.
That's not a reason not to persist.  What are needed are good tools/
idioms for dealing with it.  ORM has succeeded on that front because
the data is arbitrarily readable and writeable with standard tools, so
the engineer can always manually modify stuff to migrate it.  If a
Clojure object data store were arbitrarily readable and writeable,
then this is the first step to solving the problem.  The second step
is Ruby-style migrations.

More on that later.  ;)

Thanks,
Alyssa

-- 
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