[PEAK] A few issues and suggestions

Phillip J. Eby pje at telecommunity.com
Mon Nov 3 20:52:51 EST 2008


At 01:23 AM 11/4/2008 +0200, Sergey Schetinin wrote:
> >> 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!

Thanks for your help identifying and fixing the problems.  I've 
checked in fixes, as described here:

http://svn.eby-sarna.com?rev=2595&view=rev




More information about the PEAK mailing list