Den mån 3 jan. 2022 18:34Bram Moolenaar <Bram@moolenaar.net> skrev:
> 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").
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 -- 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/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+unsubscribe@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.
No comments:
Post a Comment