Re: Vim9 import [was Vim9 script feature-complete]
On 2022-01-04, Marvin Renich wrote: > * Bram Moolenaar [220104 12:26]: >> 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. FWIW, my preference, too, goes to using just one form: import "thatscript.vim" as that with a mandatory "as" clause. Then, I'd vote for funcrefs and consts as an aliasing mechanism, as already suggested. I find the argument that changes to an imported script may break the importing script pretty compelling, so I would withdraw my proposal of a "use that" command to indiscriminately import everything into the script's namespace. Life. -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/sr3ooo%243vk%241%40ciao.gmane.io.
Re: Vim9 import [was Vim9 script feature-complete]
* Bram Moolenaar [220104 12:26]: > Marvin Renich wrote: > > * Bram Moolenaar [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_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 --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/YdSJ6HFjh34Wek4N%40basil.wdw.
Re: Vim9 import [was Vim9 script feature-complete]
Marvin Renich wrote: > * Bram Moolenaar [220103 12:33]: > > > On 2022-01-03, Marvin Renich wrote: > > > > Don't bother with the > > > > > > > import MyClass from "myclass.vim" > > > > import {someValue, MyClass} from "thatscript.vim" > > > > > > > > syntax, and only provide > > > > > > > > import "myclass.vim" > > > > import "myclass.vim" as Other > > > > > > > > and require use of the namespace prefix: > > > > > > > > Other.MyClass > > > > > > > > The first case, without the "as" would default to the file name, with > > > > leading directories and trailing ".vim" removed > > > > > > I do not think that using a filename as an identifier is a good idea. > > > For instance, calling a script 1.vim would automatically make it > > > non-importable (without "as"). > > 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. > > Another is to do something similar to Go (a language I like, if you > couldn't tell :-) ). Every Go source file has a package statement, > «package frob», and when importing, this package identifier, «frob», is > used as the prefix (if not overridden in the import statement). > > 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? 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. > > Since a script needs to use "export" to be able to be imported, having > > to use a nice name for the script is clearly needed. The only thing is > > that it may be a long name to avoid name collisions, but then the "as > > {name}" form can be used to shorten the name. > > > > > 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). > > > But I understand that Vim9 scripts might > > > have a broader use, such as generic libraries of functions that can be > > > used by many scripts. In that context, stricter scoping rules, such as > > > in Go, are likely a cleaner approach. > > > > > > How about always requiring a prefix, but allowing explicit namespace > > > pollution? As in > > > > > > import "myclass.vim" as Other > > > use Other # Makes Other.F() available as just F() > > I like this very much; it works regardless of how the prefix gets > defined ("as" clause, vim9script statement, or cleansed filename). > > I think if I had to pick, I would require the "as" clause. It is > simple, and doesn't depend on the script author keeping the same script > ID with newer versions of the script. The author of the script doing > the importing is required to be in control. > > > 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
Re: Vim9 import [was Vim9 script feature-complete]
* Bram Moolenaar [220103 12:33]: > > On 2022-01-03, Marvin Renich wrote: > > > Don't bother with the > > > > > import MyClass from "myclass.vim" > > > import {someValue, MyClass} from "thatscript.vim" > > > > > > syntax, and only provide > > > > > > import "myclass.vim" > > > import "myclass.vim" as Other > > > > > > and require use of the namespace prefix: > > > > > > Other.MyClass > > > > > > The first case, without the "as" would default to the file name, with > > > leading directories and trailing ".vim" removed > > > > I do not think that using a filename as an identifier is a good idea. > > For instance, calling a script 1.vim would automatically make it > > non-importable (without "as"). 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. Another is to do something similar to Go (a language I like, if you couldn't tell :-) ). Every Go source file has a package statement, «package frob», and when importing, this package identifier, «frob», is used as the prefix (if not overridden in the import statement). 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. > Since a script needs to use "export" to be able to be imported, having > to use a nice name for the script is clearly needed. The only thing is > that it may be a long name to avoid name collisions, but then the "as > {name}" form can be used to shorten the name. > > > 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. > > But I understand that Vim9 scripts might > > have a broader use, such as generic libraries of functions that can be > > used by many scripts. In that context, stricter scoping rules, such as > > in Go, are likely a cleaner approach. > > > > How about always requiring a prefix, but allowing explicit namespace > > pollution? As in > > > > import "myclass.vim" as Other > > use Other # Makes Other.F() available as just F() I like this very much; it works regardless of how the prefix gets defined ("as" clause, vim9script statement, or cleansed filename). I think if I had to pick, I would require the "as" clause. It is simple, and doesn't depend on the script author keeping the same script ID with newer versions of the script. The author of the script doing the importing is required to be in control. > 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. ...Marvin -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/YdR996IMMD14X29I%40basil.wdw.
Re: Vim9 import [was Vim9 script feature-complete]
Den mån 3 jan. 2022 18:34Bram Moolenaar skrev: > > > On 2022-01-03, Marvin Renich wrote: > > > Don't bother with the > > > > > import MyClass from "myclass.vim" > > > import {someValue, MyClass} from "thatscript.vim" > > > > > > syntax, and only provide > > > > > > import "myclass.vim" > > > import "myclass.vim" as Other > > > > > > and require use of the namespace prefix: > > > > > > Other.MyClass > > > > > > The first case, without the "as" would default to the file name, with > > > leading directories and trailing ".vim" removed > > > > I do not think that using a filename as an identifier is a good idea. > > For instance, calling a script 1.vim would automatically make it > > non-importable (without "as"). > > Since a script needs to use "export" to be able to be imported, having > to use a nice name for the script is clearly needed. The only thing is > that it may be a long name to avoid name collisions, but then the "as > {name}" form can be used to shorten the name. > > > 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. But I understand that Vim9 scripts might > > have a broader use, such as generic libraries of functions that can be > > used by many scripts. In that context, stricter scoping rules, such as > > in Go, are likely a cleaner approach. > > > > How about always requiring a prefix, but allowing explicit namespace > > pollution? As in > > > > import "myclass.vim" as Other > > use Other # Makes Other.F() available as just F() > > 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. > > A kind of an alias mechanism would work. Since most of the items are > going to be functions, might as well use a function reference: > > final Func = Other.Func > This looks like a reasonable compromise. You get both a short identifier and self-documentation of where the function comes from. > That's an existing mechanism, thus keeps things simple. > > It also works for constants and read-only variables: > > const MAX = Other.MAX_VALUE > > This does not work for variables that can be set, but you should > probably use a setter function for that anyway. > > I'm just pointing out what valid pro's and con's are, I'm not suggesting > this means the alternate import syntax is best. > > -- > hundred-and-one symptoms of being an internet addict: > 208. Your goals for the future are obtaining a second Gbit connection > and upgrade your NAS to all SSD > > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net > \\\ > /// > \\\ > \\\sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ > /// > \\\help me help AIDS victims -- http://ICCF-Holland.org > /// > > -- > -- > 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 > > --- > You received this message because you are subscribed to the Google Groups > "vim_use" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to vim_use+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/vim_use/20220103173324.A57551C110C%40moolenaar.net > . > -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CADAJKhAK%3DrXACnG3h1jx3c_GLeBd9u18pM0%3DZ5p59tuvO1SKHg%40mail.gmail.com.
Re: Vim9 import [was Vim9 script feature-complete]
> On 2022-01-03, Marvin Renich wrote: > > Don't bother with the > > > import MyClass from "myclass.vim" > > import {someValue, MyClass} from "thatscript.vim" > > > > syntax, and only provide > > > > import "myclass.vim" > > import "myclass.vim" as Other > > > > and require use of the namespace prefix: > > > > Other.MyClass > > > > The first case, without the "as" would default to the file name, with > > leading directories and trailing ".vim" removed > > I do not think that using a filename as an identifier is a good idea. > For instance, calling a script 1.vim would automatically make it > non-importable (without "as"). Since a script needs to use "export" to be able to be imported, having to use a nice name for the script is clearly needed. The only thing is that it may be a long name to avoid name collisions, but then the "as {name}" form can be used to shorten the name. > 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. But I understand that Vim9 scripts might > have a broader use, such as generic libraries of functions that can be > used by many scripts. In that context, stricter scoping rules, such as > in Go, are likely a cleaner approach. > > How about always requiring a prefix, but allowing explicit namespace > pollution? As in > > import "myclass.vim" as Other > use Other # Makes Other.F() available as just F() 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. A kind of an alias mechanism would work. Since most of the items are going to be functions, might as well use a function reference: final Func = Other.Func That's an existing mechanism, thus keeps things simple. It also works for constants and read-only variables: const MAX = Other.MAX_VALUE This does not work for variables that can be set, but you should probably use a setter function for that anyway. I'm just pointing out what valid pro's and con's are, I'm not suggesting this means the alternate import syntax is best. -- hundred-and-one symptoms of being an internet addict: 208. Your goals for the future are obtaining a second Gbit connection and upgrade your NAS to all SSD /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ /// \\\ \\\sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20220103173324.A57551C110C%40moolenaar.net.
Re: Vim9 import [was Vim9 script feature-complete]
On Mon, Jan 3, 2022, 11:23 Lifepillar wrote: > On 2022-01-03, Marvin Renich wrote: > > Don't bother with the > > > import MyClass from "myclass.vim" > > import {someValue, MyClass} from "thatscript.vim" > > > > syntax, and only provide > > > > import "myclass.vim" > > import "myclass.vim" as Other > > > > and require use of the namespace prefix: > > > > Other.MyClass > > > > The first case, without the "as" would default to the file name, with > > leading directories and trailing ".vim" removed > > I do not think that using a filename as an identifier is a good idea. > For instance, calling a script 1.vim would automatically make it > non-importable (without "as"). > > 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. But I understand that Vim9 scripts might > have a broader use, such as generic libraries of functions that can be > used by many scripts. In that context, stricter scoping rules, such as > in Go, are likely a cleaner approach. > > How about always requiring a prefix, but allowing explicit namespace > pollution? As in > > import "myclass.vim" as Other > use Other # Makes Other.F() available as just F() > > Life. > I like this approach. If you don't want explicit prefixes, use the use. :) Maybe the system could be defaulted to assume the 'use' clause in case of an import without an 'as'? import 'myclass.vim' Automatically equivalent to Life's example except that Other.F() isn't allowed, only F(). > -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CANuxnEdU6Vs2oLNZFkpMN1TDBohuWPMcLV-9kEbShkBWbFY%3DBw%40mail.gmail.com.
Re: Vim9 import [was Vim9 script feature-complete]
On 2022-01-03, Marvin Renich wrote: > Don't bother with the > import MyClass from "myclass.vim" > import {someValue, MyClass} from "thatscript.vim" > > syntax, and only provide > > import "myclass.vim" > import "myclass.vim" as Other > > and require use of the namespace prefix: > > Other.MyClass > > The first case, without the "as" would default to the file name, with > leading directories and trailing ".vim" removed I do not think that using a filename as an identifier is a good idea. For instance, calling a script 1.vim would automatically make it non-importable (without "as"). 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. But I understand that Vim9 scripts might have a broader use, such as generic libraries of functions that can be used by many scripts. In that context, stricter scoping rules, such as in Go, are likely a cleaner approach. How about always requiring a prefix, but allowing explicit namespace pollution? As in import "myclass.vim" as Other use Other # Makes Other.F() available as just F() Life. -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/sqv7uk%24gb3%241%40ciao.gmane.io.
Re: Vim9 import [was Vim9 script feature-complete]
> -- > $ echo pizza > /dev/oven > Totally OT, but Bram's signature file is amazing. Yet another reason to thank him. I shall use that as an example when explaining output mechanisms from now on. -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/1e92dc34ac560a17a0158d77190956b5.squirrel%40webmail.vybenetworks.com.
Re: Vim9 import [was Vim9 script feature-complete]
Marvin Renich wrote: > * Bram Moolenaar [220103 07:07]: > > > > > On 2021-12-30, Bram Moolenaar wrote: > > > > If you have remarks on something in Vim9 script that you think should be > > > > different, speak up now! Soon we'll only make backwards compatible > > > > changes to avoid breaking existing plugins. > > > > > > There was a thread about this on HN a few days ago, and one of the > > > comments suggested to reverse the import syntax so that the imported > > > script is named first and the imported entities next. A rationale for > > > this is that it would help automatic completion. > > > > Is there another language that works like this? The current syntax > > resembles Javascript, which hopefully some users are familiar with. > > I have to agree that putting the file being imported first is much > better. > > In Go, by default every imported identifier must be prefixed by the > package name, much like the current Vim9 "as" clause. Requiring an "as" > clause (or defaulting to some form of the script name for the value of > the "as" clause), and requiring that all imported identifiers be > prefixed by this identifier make the code _much_ clearer and easier to > follow. > > I very much dislike the JavaScript style where importing, by default, > places the imported names in the current namespace rather than in a > separate namespace (identified by the "as" clause in Vim9). > > Given that even when you are only importing one identifier from a > script, the whole script must be read and executed, I think the Go way > is better. Don't bother with the > > import MyClass from "myclass.vim" > import {someValue, MyClass} from "thatscript.vim" > > syntax, and only provide > > import "myclass.vim" > import "myclass.vim" as Other > > and require use of the namespace prefix: > > Other.MyClass > > The first case, without the "as" would default to the file name, with > leading directories and trailing ".vim" removed, and with the first > letter capitalized. Non-identifier characters and leading digits would > be removed as well. In the case without "as" above, you would reference > the imported MyClass identifier as > > Myclass.MyClass > > With this, every use of an imported identifier is clear and explicit. I have to agree that the Javascript way is a bit complicated and verbose. Especially the "* as SomeName" part is not optimal: import * as funcs from "./subdir/myfunctioncollection.vim" Now "funcs" is somewhere in the middle of the line. This form might actually be the most common use. Not mentioning the items being imported has the disadvantage that it's harder to find out what is used from the imported script. But that might not be very important. You can always use "*" on the name to see what's being used. File names are often longer, thus the "import as" style can be expected to be used quite a lot. Example: import "./subdir/myfunctioncollection.vim" as funcs funcs.DoSomething() The main disadvantage is that the prefix must always be used, there is no way to use an imported item without it. But as you mention, this can also be seen as an advantage, that it's clear it is not defined in this script file. I hope others give there opinion, this is an important choice. -- $ echo pizza > /dev/oven /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ /// \\\ \\\sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20220103141413.36CB01C0A5B%40moolenaar.net.
Re: Vim9 import [was Vim9 script feature-complete]
* Bram Moolenaar [220103 07:07]: > > > On 2021-12-30, Bram Moolenaar wrote: > > > If you have remarks on something in Vim9 script that you think should be > > > different, speak up now! Soon we'll only make backwards compatible > > > changes to avoid breaking existing plugins. > > > > There was a thread about this on HN a few days ago, and one of the > > comments suggested to reverse the import syntax so that the imported > > script is named first and the imported entities next. A rationale for > > this is that it would help automatic completion. > > Is there another language that works like this? The current syntax > resembles Javascript, which hopefully some users are familiar with. I have to agree that putting the file being imported first is much better. In Go, by default every imported identifier must be prefixed by the package name, much like the current Vim9 "as" clause. Requiring an "as" clause (or defaulting to some form of the script name for the value of the "as" clause), and requiring that all imported identifiers be prefixed by this identifier make the code _much_ clearer and easier to follow. I very much dislike the JavaScript style where importing, by default, places the imported names in the current namespace rather than in a separate namespace (identified by the "as" clause in Vim9). Given that even when you are only importing one identifier from a script, the whole script must be read and executed, I think the Go way is better. Don't bother with the import MyClass from "myclass.vim" import {someValue, MyClass} from "thatscript.vim" syntax, and only provide import "myclass.vim" import "myclass.vim" as Other and require use of the namespace prefix: Other.MyClass The first case, without the "as" would default to the file name, with leading directories and trailing ".vim" removed, and with the first letter capitalized. Non-identifier characters and leading digits would be removed as well. In the case without "as" above, you would reference the imported MyClass identifier as Myclass.MyClass With this, every use of an imported identifier is clear and explicit. ...Marvin -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/YdL35xfbRHlaYZU5%40basil.wdw.