<br><br><div><span class="gmail_quote">On 9/11/06, <b class="gmail_sendername">Ryan Forsythe</b> <<a href="mailto:ryan@pdxcb.net">ryan@pdxcb.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Sep 11, 2006, at 9:42 AM, Ken Tilton wrote:<br><br>> btw, I should have mentioned that one obvious option is to simply<br>> make this<br>> a new attribute or variant of the lazy attribute, maybe "super-lazy".
<br><br>Which is what I would vote for. "Really Always Lazy"? "Always (no I<br>really mean it this time) Lazy"? I forsee some possible confusion<br>between super- and always-lazy.</blockquote><div><br>
My guess is that if always-lazy cells (as we understand them now) sometimes should propagate and sometimes should not (ie, if we cannot come up with One Right Answer) then it should be a new attribute, in which case it should be two new attributes (lazy-calculate and lazy-propagate) replacing lazy. That certainly would give developers all the options in the world (I really do not think a third "lazy-observe" attribute would be appropriate given the meaning of "observe" <g>). But...
<br><br>...I really hate introducing things without Use Cases to focus the mind. To a degree we are compromising the data integrity by letting values go out of synch with each other. Yes, they pop back into synch when read, but what about observers? If A is eager and depends on B and A has an observer that really really wants to stay on top of reality.... at this point the developer is responsible for keeping the world in order. 
<br><br>That is not necessarily a bad thing, unless it is unnecessary and can be handled automatically with more effort on the design side.<br><br>Jes thinkin out loud.<br><br>kt<br></div><br></div><br>