[PEAK] A few issues and suggestions

Sergey Schetinin maluke at gmail.com
Mon Nov 3 18:23:01 EST 2008


>> 3. Assigning Cell instances to CellAttributes.
>> When you set a component attribute to a cell (for ex. c.val = Cell())
>> it's treated as a special case and overwrites the cell in __cells__
>> dictionary. I suppose this is done to simplify use of existing cells
>> in component initialization, but there seem to be no other use for it.
>
> I was actually planning to (eventually) go more the other way, and allow
> CellAttributes to treat an assignment of a cell as triggering a changed()
> notice to the old cell underneath, after first replacing it.

I considered this, but this might have unwanted effects for rules that
expect to be triggered only if the dependencies actually changed (some
performers for example). Also, attribute-cell mapping isn't always
1:1, so even if cell values are the same one couldn't just iterate
through listeners of the old cell and create dependencies on the new
one.

Anyway, I certainly see how this feature would be useful.

>> However it's useful sometimes to have a cell as a value of another
>> cell, so it would be nice if it this special case was implemented in
>> Component.__init__ instead of CellAttribute.__set__
>
> Note that nothing stops you from making the outer cell a regular attribute.

That's exactly how I'm working around this.


Thank you for your answers!



More information about the PEAK mailing list