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

[Andi Vajda]

On Thu, 22 Mar 2007, Phillip J. Eby wrote:

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

Currently, initial keyword values that make it to the top Item __init__() 
method in repository/item/Item.py are set with user monitors disabled - it 
looks like we don't have any of these at the moment. Filter and index monitors 
are system monitors and are enabled. Last but not least, observer methods are 
invoked with the special 'init' keyword *after* all such initial values are 
set.

Andi..