[elephant-devel] Mutating slots persistently?

[Tayssir John Gabbour]

Yeah, I was hoping for something off-the-wall like, say,
(differently-named) SETF and DEFINE-SETF-EXPANDER replacements. But I
guess that's just too weird and maybe would give people the wrong
impression. ;)

Thanks,
Tayssir



Ian Eslick wrote:
> There are no tricks, this is pretty fundamental to the semantics of
> lisp.  The metaclass protocol allows you to override operations on
> slots, but not operations on arbitrary lisp objects (like complex
> numbers, cons cells, etc) so there's no way to intercede.
>
> Typically, if you're having this problem there is probably an
> opportunity to think differently about how you construction your data
> and functional abstractions.  Ask what you're trying to manipulate and
> why you want it to persist (where ordinarily you'd write a file IO
> routine to save/restore the data) and just make sure the functions that
> implement the abstraction push data to the persistent store at the
> appropriate points by, as Robert said, setf'ing the persistent object
slot.
>
> One other thought and something I do often is perform list operations
> over a set of persistent objects.  That way if I do operations on the
> car of a cons my functions side effect the persistent object (as in
> find, replace, etc).  Lists should be stored in elephant only when they
> can be done so infrequently.
>
> Elephant is, after all, a persistent 'object' store rather than a
> Persistent Lisp.  :)
>
> Ian
>
>
> Robert L. Read wrote:
>
>>Yes --- in my opinion (which gets more humble everyday), you just need to
>>reset the entire slot with setf.
>>
>>I can't think of a better solution right now.
>>
>>One could, of course, store the list as separate persistent data items, or
>>use a btree for the entire list.  This would make the change to a
>>single item
>>of the list more or less automatically saved; however, the great
>>advantage of
>>Elephant is that that it allows you to use the LISP data-space design
>>that
>>you prefer more or less directly, and changing that defeats some of the
>>advantage of using Elephant.
>>
>>
>>
>>
>>On Fri, 2006-02-17 at 12:00 +0100, Tayssir John Gabbour wrote:
>>
>>>Hi,
>>>
>>>How do people deal with the following problem... suppose I have a
>>>persistent object with a slot that holds a list. And I mutate the list
>>>with RPLACA. (Perhaps an innocent-looking SETF which expands into
>>>RPLACA.) Well, this won't be stored persistently.
>>>
>>>How do people deal with this situation? Basically just always use
>>>methods which set the entire slot? Are there any tricks to keep from
>>>having to do this?
>>>
>>>Thanks,
>>>Tayssir
>>>
>>>_______________________________________________
>>>elephant-devel site list
>>>elephant-devel at common-lisp.net <mailto:elephant-devel at common-lisp.net>
>>>http://common-lisp.net/mailman/listinfo/elephant-devel
>>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>elephant-devel site list
>>elephant-devel at common-lisp.net
>>http://common-lisp.net/mailman/listinfo/elephant-devel
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel
>