On Mon, Aug 9, 2010 at 7:01 PM, ZyX <[email protected]> wrote: > Ответ на сообщение <<Re: Can I rely on purging locks by deepcopy function?>>, > присланное в 05:16:45 09 августа 2010, Понедельник, > отправитель winterTTr: > > We have different point of views: I consider lock being an attribute of an > object (no matter how it is actually implemented), thus, in my mind, > deepcopy > purges it and so new object is no longer equal to old. >
OK, from the another point of view: we can say that the deepcopy purges the "lock" property and create a "unlock" new object. I also agree with this point of view :-) So you can enjoy this feature of deepcopy without any problem. > > Текст сообщения: > > On Mon, Aug 9, 2010 at 12:37 AM, ZyX <[email protected]> wrote: > > > Consider the following code: > > > let l=[[[]]] > > > lockvar! l > > > call add(l[0][0], l) " Results in E741: Value is locked > > > let l2=deepcopy(l) > > > call add(l2[0][0], l) " Succeeds > > > > > > Here you can see that deepcopy has purged all locks, but I do not see > > > this behavior documented in :h deepcopy(), though it is somewhat > > > mentioned in > > > > > > :h :lockvar: > > > You may want to make a copy of a list to avoid this. > > > See |deepcopy()|. > > > > Before i check the specific problem pointed by link below, as regards to > > your question > > about the deepcopy, i don't think there is any problem, it just do the > > right thing. > > Maybe the document about deepcopy does not mention about the effect to > > "lockvar", > > but the result stands to reason. > > > > > > You can refer to the document about deepcopy. > > ===> > > When an item is a |List|, a copy for it is made, *recursively*. > > Thus changing an item in the copy does not change the contents of the > > *original > > *|List| > > <=== > > > > Yes, instead of "purging" all the locks, actually, the "deepcopy" > function > > make a new instance > > of the object pointed by "l". And now, "l2" and "l" is pointing to the > > *different > > *object that has > > the *same value*. You lock the object pointed by "l", but not the object > > pointed by "l2". > > So, you can modify l2 without any locks warning, but if you want to > modify > > "l", the warning > > will come out again. > > > > > Can I rely on this behavior? I want to implement something like an > > > AlreadyChecked function from the first (and the only) answer to this > > > question: > > > > > > > http://stackoverflow.com/questions/3071476/checking-whether-some-object-h > > > as- > > > been-already-tested< > http://stackoverflow.com/questions/3071476/checking- > > > whether-some-object-has-%0Abeen-already-tested> > -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
