[PEAK] Trellis: setting @maintain attributes /
initialization rollback
Phillip J. Eby
pje at telecommunity.com
Wed Oct 8 17:52:48 EDT 2008
At 11:47 PM 10/8/2008 +0300, Sergey Schetinin wrote:
>Consider this example:
>
>class C(Component):
> @maintain(optional=True)
> def calc(self):
> return 0
>
> @maintain
> def getx(self):
> print 'get'
> self.calc
>
> @maintain
> def set(self):
> print 'set'
> self.calc = 1
>
>c = C()
>
>Depending on luck (order of hashes of get / set attr names I suppose)
>we either get InputConflict or not.
>If the get rule runs first, set rule is a conflict because the Cell is
>set by the calc rule.
>If set gets to run first, there's no conflict because calc rule
>doesn't need to run.
Actually, in that last case, the calc rule does need to run -- and
does. It's just that its output is discarded, and not considered a conflict.
>Is it possible to have calc / get rules rollback even when set runs last?
Hm. I suppose. This seems to work (line 143 of trellis.py):
if self._set_by is not ctrl.current_listener and
self._set_by is not self:
It doesn't break any of the existing tests, and adding a test for the
above (forcing the order using an __init__ method) seems to work:
def testResetCalcValue(self):
class C(trellis.Component):
trellis.maintain(optional=True)
def calc(self):
return 0
trellis.maintain()
def getx(self):
print 'get'
self.calc
trellis.maintain()
def set(self):
print 'set'
self.calc = 1
def __init__(self):
self.getx
self.set
c = C()
That is, it generates an InputConflict without the change, and prints
"get", "set", "get" with the change.
I am a little suspicious of this, even though it *seems*
correct. Mainly I worry a little about certain corner cases for
initialization, but feel free to try the patch above for now. I want
to think about this a bit more before I officially support it.
I agree, however, that it *should* be supported, because it's an
order dependency of precisely the sort that the trellis should make
impossible. I just want to make sure it covers all the bases, and
may need to think of some other test scenarios.
More information about the PEAK
mailing list