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

[Bryan Stearns]

Grant Baillie wrote:
> On 22 Mar, 2007, at 11:58, Bryan Stearns wrote:
>
>> 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...)
>
> I think, but am not 100% sure, the reindexingDeferred() is dangerous, 
> since setting attributes (in general) can cause reindexing of 
> FilterCollections that depend on those attributes.
Yes, good point -- it would be dangerous if anything in the same view 
depended on those indexes (or filtercollections) during the time that 
indexing is disabled... but if all we're doing within the "with" 
statement is attribute assignment, and we do the index updates before we 
start calling observers, I think it's safe, right?

...Bryan