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

[Phillip J. Eby]

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