On 24/06/08 05:02, Ben Schmidt wrote: > Bram Moolenaar wrote: >> Ben Schmidt wrote: >>> While working on the Float printing function, I also noted an odd Vim >>> behaviour: it won't let you assign a Float to a variable that was >>> previously a Number, and vice-versa. Or for that matter, it won't let >>> you change the type of a variable at all with an assignment. >>> >>> The trouble is in the set_var() function. Consider the following patch >>> (it is applied to my patched Vim, so line numbers will be ridiculously >>> different to the original, probably, but should apply cleanly and can be >>> found manually by :tag set_var): >> Thanks, this makes sense. Except that we should not allow conversion >> between String and Float. > > OK. I see. So the allowed changes are only those that are done > automatically anyway. > >>> The first hunk patches the variable type mismatch check so that it >>> allows floats to be included as allowed type changes. >>> >>> However, why is this check there? I don't see any reason changing a >>> variable type to or from a list, dictionary or function reference would >>> cause any problems either. References are correctly updated by a call to >>> clear_tv shortly after the check, and tv and v->tv could not reference >>> the same variable and include a change in type, so there is no chance of >>> freeing a structure that is about to be used. Couldn't the check be >>> safely removed and thus enable variables to be freely assigned values of >>> new types? >> It's called sticky type checking. Not everybody likes it, but that's >> the way it is. > > I guess it has analogies with languages such as C that use static > typing. > > But does it actually have any benefit in Vim script? I can't think of > one. I mean, do people actually see this error and think, "I made a > programming error, and I'm glad I found it," or do they see this error > and think, "Bother, I've got to work around Vim's type restrictions" > (and probably assume it's an implementation issue that can't be > avoided)? I know which I think, and was a bit astonished to find no > technical reason for it! If it truly has no benefit, why keep it? > Removing it would be like adding a new feature with essentially no > effort! > > Perhaps some others could let us know their experiences/thoughts on > this? > > Still, it is a pretty minor issue; it's easy enough, though messy, to > work around. > >>> The second hunk seems to be purely an optimisation, avoiding an >>> unnecessary call to init_tv in the else part. It applies equally to >>> Floats as Numbers, I think. >> Yes. > > OK, cool. > > Cheers, > > Ben.
If I assign a variable a numeric value, and there is no message, I might be mightily surprised if I get unexpected errors somewhere totally unrelated, where that same variable name is used as a Dictionary (not to create it, but to find the value for a certain key). Rather get the error when trying to create the Number than wherever the Dictionary would be found to have been clobbered. Of course, this argument can be equally used against reusing variable names where Vim cannot check that it's actually a different variable, hence the need for using "obviously unambiguous" variable names including e.g. the name of the script for which they are meant (not necessarily the one which gives them a value but the one in whose help they are described IYSWIM). Best regards, Tony. -- If anything can go wrong, it will. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
