Re: New package: resist!

[Alexandre Garreau]

Le sabato, 11-a de decembro 2021 22-a horo kaj 13:04 CET, vous avez écrit 
:
> > Btw, eieio-persistent (which you didn’t cite in this mail) also stores
> > one value per file, just as persist.el, so they’re technically
> > compatible.
> I think eieio-persistent occupies a weird position here.
> It’s not really an implementation of a persistent (key value) store,
> it’s more like an object oriented prin1.
> I’m not sure how to incorporate eieio-persistent into our program yet.

It’s very weird because you define one file per object… so yeah it’s not a 
store at all, it just makes objects persist.  But if anyone wants objects 
to persist all in a single store, instead of taking up a lot of different 
spare files (or at least to a predefined directory), they might want to use 
your logging kv, sqlite, gdbm, etc.

What should be implemented in eieio-persistent is a way to define a default 
place to store objects.  By default it would be, for instance, a 
directory, which would be not an object slot but a class attribute.  It 
would make so that when you create an object without specifying a “file” 
slot, the “directory” slot would be used to automatically generate a file 
in it.  And then the directory would be used to restore objects at 
startup.  There would be a global default directory defined for the class 
eieio-persistent, inherited by all persistent objects, and customizable 
through customize.  But you could define child class to eieio-persistent 
with other directories (or subdirectories, if it’s a relative path).  
Possibly, if we want to be strictly compatible with the current (by 
default, if we don’t specify a “file” slot, non-working) behavior, we could 
define a eieio-stored subclass to eieio-persistent, and only this one would 
act as I said.

Then, we could also make customizable the fact that it wouldn’t use one 
file per object, just as persist.el, but also use another backend.

But we should hack eieio-base so that eieio-persistent functions use 
persist.el