* Bram Moolenaar <b...@moolenaar.net> [220104 12:26]: > Marvin Renich wrote: > > * Bram Moolenaar <b...@moolenaar.net> [220103 12:33]: [snip] > > I agree that using the (cleansed) file name is suboptimal, but it was > > the simplest choice. There are a couple other possibilities. One is to > > require the "as" clause. [snip] > > Every vim9 script file already has a vim9script statement. You could > > say that in order for the script to be imported the vim9script statement > > must be of the form «vim9script ScriptId» where ScriptID must be a > > capitalized identifier. If you import two different scripts with the > > same script ID, you must use the "as" clause for at least one of them. > > > > Alternatively, you could require either the script ID on the vim9script > > statement or the "as" clause on the import statement. > > Adding a script ID adds another mechanism and I don't see enough > advantage in it. It raises questions, such as what happens if two > completely unrelated plugins use the same ID?
Yes, the more I think about this, the more I like requiring "as" and requiring using the prefix. > Since the import can use a relative file name, a short file name can > work. It's only when using a file name in 'runtimepath' that we can > expect the name to be longer. Thus requiring the use of "as" up front > does not seem necessary. Then we would be back to cleansing the filename. I was the one who originally suggested that, but I think that was not a great idea. Require "as" (with Capitalized identifier), and require using that identifier as prefix. > > > > I personally find that using an imported name without a prefix (as it is > > > > currently possible) makes my code terse, and I think that in the limited > > > > scope a plugin that works well. > > > > My opinion is the opposite, here. Even in small, simple scripts, the > > prefix makes the code more readable; there is no question from where the > > identifier came. > > Right. Somehow code writers can be very lazy typing things, and then > spend lots of time (possibly much later) figuring out what the code is > doing. Unfortunately I'm not aware of any studies being done on this > (it's more computer art than computer science). I think this agrees with requiring both "as" and using the prefix. > > > Throwing everything from "Other" into the current namespace is going to > > > cause trouble, because someone may add an item to myclass.vim that > > > conflicts with what is in your script. Thus extending one script may > > > break another script, that is bad. > > > > This is probably the best reason to not allow blindly importing all > > identifiers from one script into the local namespace of another. > > I'm starting to more and more like the idea of the simplistic import. The > main reason is that the Javascript way suggests that it is possible to > import individual items from a script, which in reality the whole script > is read, while some items can't be adressed. > > Also since it's possible to do this: > > import FuncOne from "thatscript.vim" > import FuncTwo from "thatscript.vim" > import FuncThree from "thatscript.vim" > > This doesn't actually load the script three times, but you'll have to do > digging in the help to know that. Thus there is some hidden knowledge. > It can be written as: > > import {FuncOne, FuncTwo, FuncThree} from "thatscript.vim" > > Which turns it into a one-liner, but adds the need for a syntax that > isn't used anywhere else. > > While using: > > import "thatscript.vim" > > Or: > > import "thatscript.vim" as that > > Is nice and short, no need for "from". The help for ":import" becomes > much shorter. The implementation will also be much simpler. > > The discussion about the need for using the prefix, whether "as" should > be required and other things, seem less important. Actually, I think the local namespace pollution is the more important issue, and requiring "as" and the prefix gives the simpler import syntax as an added benefit. ...Marvin -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/YdSJ6HFjh34Wek4N%40basil.wdw.