2017-02-23 16:25 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:
>
>> > Nikolai Pavlov wrote:
>> >
>> >> @brammool This is not fine. First, this shows yet another
>> >> inconsistency between different notations. Second, dictionary with
>> >> variables in not guaranteed to be `b:` and `let d = b:|call
>> >> islocked('d.changedtick')` errors out just in the same fashion. E.g.
>> >> consider writing a serializer which saves containers with locked
>> >> status and it is unable to serialize b: (such thing may be useful for
>> >> debugging: `:let b:` is not showing locked status). Third, ***I am not
>> >> changing a variable***. If `islocked()` attempts or it seems like
>> >> `islocked()` may attempt changing a variable this looks very strange
>> >> and makes function very suspicious. Fourth, there is an existing key,
>> >> syntactically correct and valid expression (which may even be used to
>> >> obtain `count`) and it still errors out.
>> >
>> > OK, islocked('d.changedtick') is something that should work.
>> >
>> > I never intended b:.changedtick to be a valid syntax. It's ugly.
>> > I suppose we can't make that an error now, for backwards compability.
>>
>> It is a direct consequence of existence of `b:` scope dictionary
>> variable and short form of dictionary indexing syntax, making it not
>> work would be inconsistent and not only incompatible. I sometimes use
>> things like `funccall(args).key`.
>
> I was talking about the syntax, not the semantics. Although b: behaves
> like a dictionary, it's a namespace in which members are accessed
> directly, without a separating ".".
>
>> >> By the way, why `islocked('v:count')` is zero and there are no
>> >> functions like `isfixed()`?
>> >
>> > Been like that forever. v:count is read-only, and there is no
>> > isreadonly().
>> >
>> > We can probably remove the locked flag on b:changedtick, for
>> > consistency.
>>
>> I intentionally added it there because `islocked('b:changedtick')`
>> intentionally returned 1, I did not try to understand why it does so.
>> I do not know whether somebody actually depends on that, but think it
>> is unlikely because `b:changedtick` was not previously in a `b:`
>> dictionary so whatever you did you needed to handle this value
>> separately; actually it is more likely that something will break
>> because of `b:changedtick` suddenly appearing inside a b: dictionary
>> then because of `islocked('b:changedtick')` starting to return 0 in
>> place of 1.
>
> Other read-only variables are also not considered locked. Let's keep it
> consistent.
>
>> > The locking is something under user control, with :lockvar and
>> > :unlockvar. Read-only and fixed are not properties the user can change.
>> > Thus it's not really needed to have a function to check for that.
>>
>> I do not have a use-case except that it is slightly easier to check
>> isfixed/isreadonly in Vim own tests then checking that
>> assigning/unletting fails. Does not matter much because checking for
>> failures is more robust then checking for function output.
>>
>> It would be needed if you plan on adding more such special variables
>> to scope dictionaries in the future, to make scripts forwards
>> compatible (e.g. if you need to save and restore b: dictionary
>> contents it would be good idea to honor `isreadonly()` to not get
>> error messages, now you may just special-case b:changedtick), but this
>> idea is not backwards compatible: consider a script which used
>> variable b:number and you added readonly b:number with `bufnr()` of
>> this buffer. Previously legal script suddenly broken. (I also think
>> this is what justifies user functions and commands forcing to begin
>> with upper case letter.)
>
> Making variables writeable just to be able to save/restore them is
> tricky. It opens the possibility to write any time and cause harm.
> If needed, we could add specific save and restore functions. But that's
> just in general, there can be exceptions for historic reasons...
>
> b:changedtick should never be saved/restored anyway, it only ever
> increments. That is its purpose.
I did not mean to make anything writeable. I meant that assuming you
have code which saves and restores b: variables you need to handle
cases like “variable can be saved, but can’t be restored”. There
currently is a single case with b:changedtick (or saving/restoring a
very few writeable values in v:, but I have not seen a use-cases so
far), but if there are plans on making more something like
isreadonly() would be good to have: I would normally use `deepcopy()`
and `filter(, 'isreadonly('b:'.v:key))` then than iterating over
`keys(b:)` (in which case it would be easy to check whether `let
b:{key} = b:{key}` fails): this is not only less code to write, it
also aligns will with main VimL optimization principle: the less Ex
commands the faster the code.
If b:changedtick keeps staying unique it is enough to just
special-case only it for this purpose. If there will be more in the
future then `isreadonly()` is needed to nicely keep forward
compatibility.
>
>
> --
> login: yes
> password: I don't know, please tell me
> password is incorrect
> login: yes
> password: incorrect
>
> /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
> /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\ an exciting new programming language -- http://www.Zimbu.org ///
> \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
You received this message from the "vim_dev" 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
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
