Can I rely on purging locks by deepcopy function?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Can I rely on purging locks by deepcopy function?

Nikolay Aleksandrovich Pavlov
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()|.

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-has-
been-already-tested

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Can I rely on purging locks by deepcopy function?

winterTTr-2


On Mon, Aug 9, 2010 at 12:37 AM, ZyX <zyx.vim@gmail.com> 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-has-
been-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
Reply | Threaded
Open this post in threaded view
|

Re: Can I rely on purging locks by deepcopy function?

Nikolay Aleksandrovich Pavlov
Ответ на сообщение «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.

Текст сообщения:

> On Mon, Aug 9, 2010 at 12:37 AM, ZyX <[hidden email]> 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>

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Can I rely on purging locks by deepcopy function?

winterTTr-2


On Mon, Aug 9, 2010 at 7:01 PM, ZyX <[hidden email]> 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 <[hidden email]> 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