Re: Vim9 import [was Vim9 script feature-complete]

* Bram Moolenaar <Bram@moolenaar.net> [220104 12:26]:
> Marvin Renich wrote:
> > * Bram Moolenaar <Bram@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_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/YdSJ6HFjh34Wek4N%40basil.wdw.