def! in legacy vimscript

[Maxim Kim]

Shouldn't def functions be prohibited in legacy vimscript?

https://vi.stackexchange.com/questions/36829/how-can-i-define-vim9-functions-and-vim9-lambdas-in-a-vim9-script

Basically if you add

def! Hello()

    echo "hello world"

enddef

to a regular legacy vim file (.vimrc, for example), function Hello is globally defined and one can :call Hello() and get echoed "hello world".

[Bram Moolenaar]

In case you have some code that needs to be executed fast, but the rest
of the script has some stuff you don't want to convert to Vim9, then
putting that code in a compiled function is very useful.

Wether a function is script-local or global (when not using a "s:" or
"g:" prefix) depends on the script it's defined in. An alternatie could
be to make :def functions always script-local by default, then you would
have to use "g:" to make them global. I don't think this helps and it
can be confusing.

The rule is "at the script level, the type of script defines what the
scope of the items is". I think that's easy to understand.

--
Keyboard not found. Think ENTER to continue.

/// 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 ///

[puremo...@gmail.com]

> Wether a function is script-local or global (when not using a "s:" or 

"g:" prefix) depends on the script it's defined in

> The rule is "at the script level, the type of script defines what the 
scope of the items is". I think that's easy to understand. 

You know, I think the other rule is arguably easier to understand: "def functions are always script-local".

What are people's thoughts ?

 In a sense the rule above could be used to advantage for "internal linkage" functions of a plugin. For example:

- I have a "public" interface of "function" functions - these are legacy vimscript for compatibility/interop

- internally in my "plugin" (let's say a single .vim file), I have some def functions for performance, convenience - they are script-local by default.

I admit the current behaviour is not difficult to explain or learn, but perhaps the "def functions are always internal unless "exported" or "g:" prefixed" is simpler logically?

[Bram Moolenaar]

> > Wether a function is script-local or global (when not using a "s:" or
> > "g:" prefix) depends on the script it's defined in The rule is "at the
> > script level, the type of script defines what the scope of the items
> > is". I think that's easy to understand.
>
> You know, I think the other rule is arguably easier to understand: "def
> functions are always script-local".
>
> What are people's thoughts ?
>
> In a sense the rule above could be used to advantage for "internal
> linkage" functions of a plugin. For example:
>
> - I have a "public" interface of "function" functions - these are legacy
> vimscript for compatibility/interop
> - internally in my "plugin" (let's say a single .vim file), I have some def
> functions for performance, convenience - they are script-local by default.
>
> I admit the current behaviour is not difficult to explain or learn, but
> perhaps the "def functions are always internal unless "exported" or "g:"
> prefixed" is simpler logically?

Making :def functions always script-local would be OK. But how about
legacy functions? If we connect the visibility to the type of function,
you would expect a legacy function in a Vim9 script to be global. But
in a Vim9 script everything is script-local. We even removed using "s:"
for script level items.

So then the rule for :def functions would differ from legacy functions,
which I find confusing. If we make the script type define the
visibility of items it's simpler and more logical.

--
hundred-and-one symptoms of being an internet addict:
64. The remote to the T.V. is missing...and you don't even care.

[Ben Jackson]

OK, makes sense, thanks.