Re: propoal: persistence though id

[email protected] wrote:

> i'm new to this list, but have read a few hundred posts, still,
> apologises if this is in any way a repeat,
 > anyway here's a proposal, it's about persistence,

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

 > persistence, it seems to me, needs to be at the core of a language,

I agree.  Prothon has features built into the objects for persistance.

> i
> have looked at a mix-in class to confer persistence, but when i
> started thinking about it, i found the real problem is not how an
> object is represented, but how generally it can be identified.

Prothon has the concept of "object identity".  There is a bit in an object
that when set guarantees that an object will stay where it is.  That is it
will exist as a named attribute of a module and that name and module name
will not change during the execution lifetime of the interpreter.  It also
means that the same object will exist in all interpreters everwhere whenever
that same module is loaded.

> an objects 'id', or identity, is just something that, when equal to
> another id, means you've got two references to the same object. Using
> memory addresses for id's, works well and by doing so, i think its
> telling us something more fundamental, maybe that an 'id' is actually
> showing how an object can be located.
>
> So, in a way, rather than id
> being 'identity', which seems to me to imply an abstract reference,
> id could be 'identify', which implies something more dynamic.

Prothon has an identity function that when given the module name and
attribute name of an identity object, returns that identity object.  If the
module isn't loaded it loads the module.

> so the idea is to be able to set an objects id to a resource
> reference, and in particular, to the most ubiquitous reference system
> out there, URL's.
>
> but in the simplest case the 'id' could just be a local file name,
> and cause an object to be automatically persisted to that file.

This sounds like a great way to extend the existing identity concept in
Prothon beyond the interpreter's boundaries.  You don't have to give
identities to every object.  You only need to have global identities on key
objects like containers and others are maintened relative to those.  That is
how Prosist already works.

The Prosist identity objects could have the URL or file name references as
you suggest.

> examples:
>
> 1.  small objects with a file name id, would just be dynamically
> persisted all the time, like database records, with object locking
> being used to drive file locking. ( then do you actually need a
> memory representation?  isn't this what might happen on a system
> where the memory was static, and the distinction between memory and
> files was only a matter of format. )

Prosist already uses object locking to manage objects in a file.  It could
easily be extended to support file locking and support multiple interpreter
access.

> 2.  larger saving/loading of settings/data etc. could be a collection
> of object references, made with a file name id, then by locking,
> updating any references and unlocking, all the objects could be
> stored/retrieved in a single access. ( won't this be just like a
> settings file, or a registry, if the file were stored in a user
> dependent area.)

Prosist already does this.

> Also a URL could specify the format, using the protocol, eg
>
> FILE: bespoke format
> HTTP: human readable format  ( XML with styles? )
>
>
> Note: doesn't this have similarities to Java's use of a domain name
> in class/file locating.
>
>
> and now for something blue sky,
>
> what starts out as storage, ie pull technology, can be expanded to
> push/pull.  Remote setting and retrieval of data via a URL is already
> well established.  push/pull can be used for communication,
> communication with a user is a GUI, so a connection to a document
> object model, could allow a very nice, browser based, user interface
> that could take advantage other browser resources. ( 2D, 3D, speech
> etc.)

Sounds cool....