Re: Re: propoal: persistence though id

[email protected] wrote:

> sorry for the delay in this,
>
>> This is not a repeat and I like your thinking.  You do owe it to
>> yourself to study up on Prosist though as some background on what
>> already exists in Prothon persistence.
>> http://prothon.org/prosist.htm
>
> ough, i did, actually i read all the documentation, and played with
> most of the test suit, obviously forming opinions of the various
> ideas and implementations of things, as i went.  what i thought about
> prosist was that it had a cleaner interface than Python's, and had
> extra useful features, but it was just that i think there's an even
> more central role for persistence,
>
> the best way to persist objects has to be in a way that they can just
> be regarded as file objects, with only performance differences to a
> memory object, so no saving or loading, a file based object just
> 'is', it isn't a maintained duplicate of a memory object.
>
> i think its the maintenance of the duplication, rather than the
> persistence, which causes the need for the Prosist Modes, the Modes
> representing an unnecessary distinction between memory and file
> objects. maintained duplication, as distinct from multiple
> referencing, might be another core principle worthy of its own
> separate methodology, after all its seems to me to be technically the
> same thing as synchronisation.
>
> if a file object was a container, wouldn't it be a module?

You could consider it that if you wished.  You would have to add the hooks
to import it.  Prosist could already do that if you wished.

> if all the objects in a program were file objects, couldn't a program
> just be paused rather then shutdown and restarted?

Unfortunately many objects cannot be represented as persistant objects.
Most C-based objects for example.

> could program pausing be accomplished with persisted thread objects?

We have been discussing this lately.  We are about to implement new
lightweight threads that can be paused and stored in Prosist.  Our regular
threads cannot because of C functions.

> i think a simple and fairly obviously syntax for this would be to
> extend the object function:
>
> reference= Object(objectReference)
>
> without objectReference, obviously the normal behaviour of creating a
> new object with just Object as a prototype would occur, if
> objectReference were a file name, then reference would become a file
> object and the object id would be the file name.

Creating a new type that was based on a file and was automatically
persistant is an interesting concept.  It sort of turns Prosist on its head.
I lilke this idea.  It could reuse much of Prosist's code.

I think it would co-exist with Prosist.  There are times when you would want
to take an object tree created by some other code and use Prosist
after-the-fact to store the tree, and in other applications you would want
to start with your persistant file-based object and go from there.

What would you call this type?  It is file-based.  You would want it to be a
container or it would be useless.  Would you make it a dictionary?  Why not?
Maybe make two versions, a list and a dict.  Call them FileList and
FileDict?

Wait a minute.  What is the difference between this and opening a Prosist
database with a root of a list or a dict?  Is there really any difference?
You could argure that a FileList doesn't have to do the commit operation or
a flush, but that is a disadvantage.  The only way to avoid a commit or a
flush is to do one on every modification and that is a performance problem.
There is a reason that files have flushes and commits.

I think that what you are asking for is a pipe dream.  You'd like for the
differences between objects and files to disappear but the differences are
very real and can't go away by wishing them away.  Correct me if I'm wrong.