[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.