[PEAK] Re: Trellis-fork

[Sergey Schetinin]

I've also added the means to use this from Component / @compute etc layer.


from mext.trellis.trellis import *

class T(Component):
    x = attr(1)
    x_observed = x.observed # <- this is new

    flag = attr(False)
    log = make(list)

    @maintain
    def observer(self):
        if self.flag:
            self.x

    @perform
    def status(self):
        self.log.append(self.x_observed)

t = T()
assert t.log == [False]
t.flag = True
assert t.log == [False, True]
t.flag = 100
t.x += 1
assert t.log == [False, True]
t.flag = False
assert t.log == [False, True, False]


On 2009-06-26, Sergey Schetinin <maluke at gmail.com> wrote:
> Oh, and I forgot to mention that if you want to, you can actually do
>
>  cell.has_listeners_cell.has_listeners_cell.has_listeners_cell.value
>
>  Now that's meta :)
>
>
>  (Those cells will get garbage collected unless reference is saved
>  somewhere, like in a subject list :)
>
>
>
>
>  On 2009-06-26, Sergey Schetinin <maluke at gmail.com> wrote:
>  > If you were working Sensors and Connectors it could have crossed your
>  >  mind that connect and disconnect methods are actually a kind of event
>  >  handlers themselves -- the event being the change in presence of
>  >  listeners to the sensor. That is events effectively being "we want to
>  >  observe this cell (a LazyCell for example)" and "not anymore". But at
>  >  the same time the implementation of this event handling was completely
>  >  different from what Trellis generally offers -- you actually need to
>  >  provide the event handlers instead of just observing some cell.
>  >
>  >  The changes I've committed today change that -- every cell, even a
>  >  Value gets a .has_listeners attribute that acts as a cell -- if you
>  >  read it from a rule it will retrigger it when the cell gets any or
>  >  loses all its listeners. One of the things this buys you is that
>  >  connect / disconnect don't have to be very fast operations anymore.
>  >  Imagine a cell representing some remote data, establishing the
>  >  required connection, asking the server to send updates and other
>  >  bootstrapping might take a while, with this change it doesn't have to
>  >  happen inside single transaction anymore.
>  >
>  >  Another reason why this is useful is that it allows one to make
>  >  normally passive cells become active by means of some external
>  >  component. It would work like this: if a Value is observed --
>  >  .has_listeners -- make arrangements to update it as necessary. It's
>  >  good to know that the same would work even if the target cell is not a
>  >  Value which is something that makes the alternative strategy (replace
>  >  cells with our own implementation) more fragile. The downside is that
>  >  unless subscribed to that Value would just stay out of date.
>  >
>  >  Another result is that LazyCell is not a Sensor anymore, but a direct
>  >  descendant from ReadOnlyCell.
>  >
>  >
>  >
>  >  --
>  >  Best Regards,
>  >  Sergey Schetinin
>  >
>  >  http://s3bk.com/ -- S3 Backup
>  >  http://word-to-html.com/ -- Word to HTML Converter
>  >
>
>
>  --
>  Best Regards,
>  Sergey Schetinin
>
>  http://s3bk.com/ -- S3 Backup
>  http://word-to-html.com/ -- Word to HTML Converter
>


-- 
Best Regards,
Sergey Schetinin

http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter