Re: A few issues and suggestions
"Phillip J. Eby" <pje-Wh6+Hckhi6HFNGf7iClzIwC/[email protected]>
| Newsgroups | gmane.comp.python.peak |
|---|---|
| Message-ID | <[email protected]> |
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