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

[Phillip J. Eby]

At 02:16 PM 3/22/2007 -0700, Andi Vajda wrote:

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

So, should I use _setInitialValues() in schema.Item.__init__ to do the 
attribute setting?  It seems like there may need to be more collaboration 
between schema.Item and repository.item.Item in order to enable the 
behavior I'm trying to add.

At the moment, anything done by schema.initialValues() is going to show up 
as a regular attribute change, if I understand correctly.