To persist or not to persist ?

[Laurent Martelli]

>>>>> "Tril" == Tril  <dem@tunes.org> writes:

  Tril> On 14 Oct 1999, Laurent Martelli wrote:

  >> What would you chose : explicit save or explicit delete ?

  Tril> You have to have both contexts.  When you are working, as a
  Tril> configuration option, you choose your preference, which then
  Tril> becomes "default" for creating new objects.  The default can
  Tril> be overridden in specific instances, or you switch contexts.

Yes, this is probably the best thing to do, since no solution is
really better than the other. 

  Tril> This is how we should handle decisions like this in every
  Tril> case.  Another case is garbage collection, do you want
  Tril> explicit deleting of data, or do you want it automated?  So GC
  Tril> should also be "configurable."

Right now, GC is done only when I quit the interpretor, when all
objects are saved. I use a simple reachability method; lambdas and a
variables are considered root objects, and any object reachable from
these are saved. Given this, we only need to configure the root
objects, since objects that are unreachable from these are unreachable
at all. 

But there may be another issue with `delete'. Currently, an objects
marked deleted is removed from the root objects set, but if it is
reachable from another root object, it will be saved anyway. This is
to avoid "invalid pointers". But we could also state on can really
delete any object, and check references when we use them, and raise an
exception if needed. 

  Tril> Necessarily, making everything configurable leads to a lot of
  Tril> configuration, so we need a powerful configuration mechanism
  Tril> to handle defaults (contexts) and to shift between them (both
  Tril> for new work and for changing groups of old data).

  Tril> What is this configuration mechanism?  I prefer to fully
  Tril> integrate it with the rest of the system.  That means using
  Tril> function arguments for configuration options, and partial
  Tril> evaluation to select contexts.  If we do this, the
  Tril> configuration mechanism is "already there."

  Tril> I'm not sure of the details of the system you are developing
  Tril> (I haven't been following too closely), so I don't know if the
  Tril> same solution will work for you.

I think that it should work.

-- 
Laurent Martelli
martelli@iie.cnam.fr