On 9/11/06, Ryan Forsythe ryan@pdxcb.net wrote:
On Sep 11, 2006, at 9:42 AM, Ken Tilton wrote:
btw, I should have mentioned that one obvious option is to simply make this a new attribute or variant of the lazy attribute, maybe "super-lazy".
Which is what I would vote for. "Really Always Lazy"? "Always (no I really mean it this time) Lazy"? I forsee some possible confusion between super- and always-lazy.
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...
...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.
That is not necessarily a bad thing, unless it is unnecessary and can be handled automatically with more effort on the design side.
Jes thinkin out loud.
kt