Monday, January 3, 2022

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

Marvin Renich wrote:

> * Bram Moolenaar <Bram@moolenaar.net> [220103 07:07]:
> >
> > > On 2021-12-30, Bram Moolenaar <Bram@moolenaar.net> 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 -- Bram@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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20220103141413.36CB01C0A5B%40moolenaar.net.

No comments: