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

[Bryan Stearns]

Phillip J. Eby wrote:
> In discussion with Morgen, Bear, and John, we've determined that the 
> optimum way to support fast dump and reload with proper support for 
> multiple inheritance and type changes due to sharing, is to get rid of 
> custom __init__ methods for Item subclasses.
> [...]
> The second feature is a new 'schema.initialValues()' function that you 
> can call in the body of a class to define how the class' attributes 
> should be initialized.  For example:
>
>     class ContentItem(Item):
>         ...
>         schema.initialValues(
>             createdOn = lambda self: datetime.now()
>         )
>
> In other words, keyword arguments are used for the attribute names, 
> and the values are functions taking the item as an argument and 
> returning the desired attribute value.  The attributes are *not* 
> limited to schema attributes; they can be transient attributes or even 
> properties, and they override any values defined in a superclass or in 
> the attribute's "initialValue" aspect.  This also eliminates the need 
> for __init__ to supply default values for keyword arguments or to 
> change default attribute values established by base classes.
>
> 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...)

...Bryan