[PEAK] Re: trellis.Set.discard

[Phillip J. Eby]

At 12:58 AM 11/1/2008 -0400, Phillip J. Eby wrote:
>At 05:27 AM 11/1/2008 +0200, Sergey Schetinin wrote:
>>Sorry to bother you if this was answered already, but that will only
>>fix the readonly issue, right?
>>
>>This one:
>>
>>class C(Component):
>>     x = attr()
>>     @maintain
>>     def rule(self):
>>         self.x = 10
>>
>>@atomically
>>def test():
>>     C().x = 1
>>
>>and the new discrete rules not resetting immediately after init are
>>still outstanding, correct?
>
>Correct.
>
>
>>Any decision on those?
>
>I suppose it might work to have new cells' _finish() methods called 
>at the end of a component creation "transaction".  That would fix 
>both problems, I think.  (Though I'm not sure it would work 
>correctly for new discretes with active readers, as a changed() call 
>occurs in that case, and would result in some of the newly scheduled 
>cells being recalculated.)
>
>I'll need to think about it some more when I go back to working on this.

Okay, I'm working on this now, so let's think about it.  ;-)

If we _finish() all cells at the end of this "pre-transaction", then 
cells set as part of initialization will become writable again, which 
is good.  Discrete cells (whether rule or value-based) will also 
reset their values, and mark themselves as changed.

By itself, that seems okay and correct.  Now let's consider what 
happens if the value was read by a cell within the 
pre-transaction.  I think we can establish that this is also safe.

Consider that during a pre-transaction, a new cell's value can only 
read be read by another new cell.  This is because by definition, the 
pre-transaction must occur within a single rule execution (or 
non-rule code), and thus only uninitialized rules may be run.  (A new 
cell's value can be set, however, by either the calling rule or by a new rule.)

 From this it follows that the only rules that can be re-run by 
resetting a new discrete cell after the pre-transaction, are rules 
which cannot yet have run in the overall transaction.  Thus, the cell 
value reset simply leads to the rule being scheduled to execute later 
within the current transaction -- thereby allowing it to correctly 
see the reset value.

Okay, I think this will work, then.  I do need to verify the current 
usage of _finish() does not do anything else that might conflict, and 
then make _finish part of the AbstractCell class (so that e.g. 
Constants don't have problems).