>>> 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. >> > 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.
Mmm. I thought of that. But you'll get equal or worse behaviour if a Number is clobbered by another Number, or a String by another String, and variables with generic names are likely to hold the same datatypes: I mean, if you name something 'n', it's likely to hold a number. If you name something myplugin_n, you are very unlikely to get a clash. So I think the cases where this actually occurs and is helpful are very rare. However, wanting to convert a variable into a specific type to ensure it is interpreted certain ways by later code is relatively common, I think. How about this compromise, which I think offers the best of both worlds?: Allow types to be changed for local variables, arguments and script variables, since nobody but that coder should be messing with them, so the freedom of type changing is not dangerous, but disallow it for global, window, buffer and tab variables. You're much more likely to want to do a type conversion in a local context anyway, because the most likely place for a datatype to go wrong and need conversion is in a hand-typed function call; script-writers will usually get it right (perhaps after debugging!) and global variables, etc. are usually set in a .vimrc by copying an example, or set by scripts, so the script-writer is involved again, keeping the type on track. Ben. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
