[PyCells] [cells-devel] Call for comment on Prospect of Lazy Cells Not Propagating Either

Ken Tilton kentilton at gmail.com
Mon Sep 11 18:00:44 UTC 2006


On 9/11/06, Ryan Forsythe <ryan at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060911/712a3815/attachment.html>


More information about the cells-devel mailing list