On Tuesday, January 4, 2022 at 6:26:07 PM UTC+1 Bram Moolenaar wrote:
>
> Marvin Renich wrote:
>
> > * Bram Moolenaar <br...@moolenaar.net> [220103 12:33]:
> > > > On 2022-01-03, Marvin Renich <mr...@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.
>
> 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?
>
I see an important disadvantage: with this system, if in the importing
script you don't explicitly rename the namespace, then when reading the
source it isn't possible to know that after
import foobar.vim
call ScriptID.Function()
the ScriptID is defined by a statement in foobar.vim. If the "implicit
namespace" were easily deductible from the script name (as it already is in
the autoload mechanism) then you would have, maybe,
import foobar.vim
call foobar.Function()
or something similar, which is much more transparent.
>
> 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.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.
>
> --
> A scientist is someone who knows exactly how an engine works, but
> can't fix his car when it fails to start.
> An engineer is someone who knows only some things about an engine, but
> can fix his car when it's broken.
>
> /// Bram Moolenaar -- br...@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_mac" 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_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_mac+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_mac/68a97db3-e1ff-479e-a046-add3ed5a4874n%40googlegroups.com.
