Phillip J. Eby wrote:
At 11:58 AM 3/22/2007 -0700, Bryan Stearns wrote:
Phillip J. Eby wrote:
The order that individual attributes will be set in is not
guaranteeed, but they are *all* set before your __setup__ method is
called. Any keyword arguments passed to __init__ will prevent that
attribute value from being calculated - it'll just be set from the
keyword before __setup__ is called.
Can you please wrap this initialization with:
with view.observersDeferred():
with view.reindexingDeferred():
# change item class here
# do initialization here
so that observers don't fire until the state of the object is
consistent? (I don't know whether disabling indexing is important,
but I don't think it'll hurt...)
Do we do this during __init__ now? I'm just wondering.
AFAIK, when doing **kwd initialization of items, the repository already
defers firing observers on that item until all of the kwd initialization
is done. However, we had bugs where we were using **kwd initialization
to set up a bidirectional reference to another item, and the other item
was observing the other end of the biref, and the repository didn't
defer that observer from firing. (The case: Reminders.remindable is a
biref to Remindable.reminders, which Remindable had an observer on -- if
we passed the remindable in as a kwd argument when creating a Reminder,
the Remindable's observer could (and did!) get called before other
attributes on the Reminder were set up. I changed the cases I found
where we did this, to assign the remindable after the Reminder was
otherwise constructed -- this was before we had the observersDeferred
mechanism, though.)
When the class changes, the order of attribute change is that the
__class__ will change, then any initialValues() declared by the
subclass that are *not* already defined by the base class. In other
words, only attributes that didn't exist before would be initialized.
Finally, the __setup__ would run.
So, I guess I don't understand why we need the deferrals. It doesn't
seem like there'd be anything watching the subclass attributes, since
they didn't exist until the class changed. I'm not sure at what point
observers kick in, either, but IIUC they would be triggered *now* by
anything you set during __init__, so I don't see where this is a
change. Maybe an example of a specific case would help me understand?
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
