[Chandler-dev] Getting rid of all __init__ methods (for Item subclasses)

[Bryan Stearns]

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?
>