To persist or not to persist ?
14 Oct 1999 11:33:35 +0200
>>>>> "Tril" == Tril <firstname.lastname@example.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
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.