> > How about introducing a second part to the api? (store) creates a > > wrapper for the persistent address, and refp then takes one of those > > wrappers and the name? > > I like that. I would go one step further and say refp should have a > default data store that is used unless you specify anything else via > 'store' or additional arguments to refp. This would go partway > towards making "persistence like garbage collection".
Great suggestion! > The reason I suggested persisting entire nampespaces was that > sometimes (often) the need to persist data is outside of any usage of > refs (or atoms, or agents). Maybe such a high-level facility could be > built on top of refp. I disagree. There three kinds of identities - those that mutate in a multi-process environment, those that mutate in a guaranteed single- process environment, and those that don't mutate. If you can make outside changes to the underlying data store at runtime (DB or even properties file), through either another JVM or manually, then it's inherently multi-process. Multi-process mutation of identities belong in refs et al. The second case, mutation in a single-process, is synonymous with vars in Java/Clojure, where logical processes are VM threads. The problem is that vars are thread local; how in the heck do you name the thread- specific var for persistence? And read from them, given that the next time the number and nature of threads will be different; how do threads in a future VM map to threads in a previous one; threads are inherently volatile. I see the use case of long-running processes having a clear identity and needing to persist/recover state, but it's a much smaller use case than the first (multi-process mutation). Identities that don't mutate are like defonce, where the db state being read is locked for the duration of the VM. The only real use case is a properties database that can only be edited when the VM is shut down. I guess what I don't see is why you would need to OFTEN persist data outside of refs... The second case, though legitimate, seems minor, and can be easily modeled with the first. The third case (the properties database) is very often, but should easily be addressed by libs (though I agree it should be part of the language). I guess what I'm saying is that we should probably be using refs if persistence is required. > Another thing I'd like to see (as I mentioned) is an extension of map > syntax for the kinds of (e.g. SQLish or XMLish) data structures you > get out of persistent stores. One of the brilliant things about > Clojure is its unification of multiple sequence types. It was > something that was crying out to be done. I think that, similarly, > there could be a more unified and standard way of dealing with maps, > maps-of-maps, maps containing lists, etc. There must be someone on this list who can develop a formally correct regular expression language for hierarchical data. The formal correctness part is not my strong suit. I'm not too familiar with XSL, but would a less verbose version of that work? 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
