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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
