Persistence

[BRIAN SPILSBURY]

> BRIAN SPILSBURY wrote:
> > But the loss of transparency here is over a much smaller domain than
> > restricting persistence to special applications which explicitly access
> > a database. Casual persistence is useful and nice for most applications.
> 
> Okay, so we've got exceptions to transparency for transactions and for
> "weak references." Now what about programs that build up data structures
> in memory that are more efficient to re-create than to store? They must
> be careful to explicitly dump pointers to them when they get a message
> to shut down (assuming they get such a message). That seems like another
> exception to transparency.

Those aren't really exceptions to transparency. The weak-refernces are just
like symbols only invisible, you only get to touch what's on the other end
which may change to nil at some point. In an implementation we can leave
out that 'symbol like' intermediary completely and let the garbage collector
deal with it.

The support for transactions with 'synchronous blocks' is likewise
transparent once set up. I could have _everything_ being synchrnous
and I wouldn't notice except that writes would get slower.

The ability to place objects in a given chunk may get irritating
but for things that don't care it doesn't matter, for things that 
care it wouldn't be transparent anyhow.

I don't see the problem here. The only issues are in allocation, and then
only for objects that care about it.

Brian