* Bram Moolenaar <Bram@moolenaar.net> [220103 12:33]:
> > On 2022-01-03, Marvin Renich <mrvn@renich.org> 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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/YdR996IMMD14X29I%40basil.wdw.
No comments:
Post a Comment