[Persistence-sig] "Straw Baby" Persistence API

Tim Peters tim@zope.com
Mon, 22 Jul 2002 16:43:25 -0400


[Guido]
> I've often thought that it's ugly that you have to set _p_state
> and _p_changed, rather than do these things with method calls.
> What do you think about that?  Especially the conventions for
> _p_state look confusing to me.

[Jeremy Hylton]
> I would like to keep a simplified version of _p_changed,

If _p_changed is a 1-bit flag now, how much simpler can it get <wink>?

> but not _p_state.  The purpose of assignment to _p_changed is to mark an
> object as changed.  Assignment seems clear here.  _p_changed is a
> flag, normally false; when an object is changed, it is set to true.
> Why would a method call be any clearer?

Presumably so that interested parties could influence what happens when an
object becomes "dirty"?  Maybe update a distributed cache, who knows.  I
suspect Philip Eby was getting at something related with his plea to set
_p_changed only after an object is an a sane state again after a change is
complete.

OTOH, method calls are a large overhead whem the mutation is simple; e.g.,
if a persistent list has to call a changed() method every time someone does

    a[i] = 6

that's a real drag on potential performance.