[PEAK] A few issues and suggestions

[Sergey Schetinin]

I applied the suggested fix and it resolved the issue in the app as
well, thanks!

I see how it wouldn't work for AddOns though, so I guess it's better
to avoid mixing Components and Addons, or at least only create them in
top-level, non-undoable code and not inside rules.

On Tue, Nov 4, 2008 at 22:14, Sergey Schetinin <maluke at gmail.com> wrote:
> On Tue, Nov 4, 2008 at 16:36, Phillip J. Eby <pje at telecommunity.com> wrote:
>> I don't see from this example why .c's initialization *shouldn't* be undone,
>> unless you're saying that the make() isn't also being undone...  in which
>> case the test should be about that.
>
> You're right, but in the app it wasn't obvious that the problem is
> with make, what was apparent is that some changes from __init__ don't
> stick. So, I didn't know what the problem is exactly, until I figured
> out the test case.
>
>> It seems to me that the real issue here is that CellAttribute and
>> TodoProperty don't undo-log their addition of a cell to a Component's
>> __cells__.  I didn't originally do this because then the Cells() addon would
>> need to support locking to be able to be threadsafe in the future.  But I
>> suppose that bridge can be crossed later.
>>
>> Is there any other reason besides this inconsistency, that the component
>> __init__ shouldn't be undone?
>
> No, I think this is it.
>
>> (Btw, the same problem occurs with cells in addons and services, and won't
>> be fixed by undo-logging the cell creation.  It's a big open issue at the
>> moment, since even avoiding an __init__ doesn't help.  In essence, undo
>> logging and "write-until-read" consistency simply don't mix, and  Addons,
>> services, and the Cells() map all run off the write-until-read model.)
>>
>> At 05:09 AM 11/4/2008 +0200, Sergey Schetinin wrote:
>>>
>>> Here's the test case:
>>>
>>> class C(Component):
>>>    x = attr(0)
>>>    def __init__(self):
>>>        self.x = 10
>>>        @on_undo
>>>        def undo():
>>>            print 'UNDO'
>>>
>>>
>>> class TC(Component):
>>>    c = make(C)
>>>    x = attr(0)
>>>    y = attr(0)
>>>
>>>    @maintain
>>>    def test(self):
>>>        if self.x:
>>>            self.c
>>>            self.y
>>>
>>>    @maintain
>>>    def write(self):
>>>        self.y = self.x
>>>
>>>
>>> tc = TC()
>>>
>>> @atomically
>>> def test():
>>>    tc.x = 1
>>>    tc.test
>>>
>>> print tc.c.x
>>>
>>> # prints UNDO \ 0
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Nov 4, 2008 at 04:51, Sergey Schetinin <maluke at gmail.com> wrote:
>>> >> Thanks for your help identifying and fixing the problems.  I've checked
>>> >> in
>>> >> fixes, as described here:
>>> >>
>>> >> http://svn.eby-sarna.com?rev=2595&view=rev
>>> >
>>> > Thanks a lot. However, I see that some problems, that I thought was
>>> > related to my monkeypatching, didn't go away, what happens in effect
>>> > is that changes done Component.__init__ get rolled back. I'm working
>>> > on a test case for this, and I've noticed something I didn't think
>>> > about before. In the following example __init__ reads data it
>>> > shouldn't. This isn't a problem normally, but something to keep in
>>> > mind when writing components' __init__
>>> >
>>> > class TC(Component):
>>> >    y = attr(0)
>>> >
>>> >    def __init__(self):
>>> >        print self.read # 0
>>> >
>>> >    @compute
>>> >    def read(self):
>>> >        return self.y
>>> >
>>> >    @maintain
>>> >    def write(self):
>>> >        self.y = 5
>>> >
>>>
>>>
>>>
>>> --
>>> 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