Ok. For starters, it seems that you *can* call a numbered function
from anywhere:
function! s:T()
echomsg "here"
echomsg 'SID=' . expand( '<sfile>' )
endfunction
let F=function('s:T')
echomsg F()
let F1 = function( '<SNR>66_T' )
echomsg F1()
echomsg string( F )
let s:dict = {}
function s:dict.init() dict
echomsg "in dict function"
endfunction
unlet! F2
let F2 = s:dict.init
call call(F2,[],{})
" Note: F2 is a global, so the numbered function declared for a local dict
" is available to call globally.
On 6/29/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
When Funcref's were introduced in Vim7, I expected them to work for
script-local functions, across scripts. The documentation didn't say
that, but it didn't say that it wouldn't either, and I thought that that
is one of its biggest uses (other than the actual intended
functionality, which is for implementing numbered functions). However, I
found that the Funcref references for such functions can't actually be
passed out to other scripts. This reduces the usefulness of this feature
as we can't register private functions to receive callbacks from other
scripts.
What is weird is that the the Funcref() actually behaves exactly like
the function name itself. Say you have a function called s:T() and say
the script id is 60. The Funcref obtained via function('s:T') can't be
called from outside the script, but if the Funcref is obtained using
function('<SNR>60_T'), then it will be fine. Also, a Funcref obtained
using these two methods will not be to the same object, though you would
expect them to be. The below echoes 0:
echomsg function('s:T') is function('<SNR>60_T')
where as the below echoes 1:
echomsg function('s:T') is function('s:T')
In this case you are *not* creating numbered functions, so the string
value you use is what gets stored.
The above two facts make Funcref counter-intuitive to understand. I
actually wonder why even a special function called function() was
required to obtain the Funcref in the first place (unlike in Python).
There are other aspects of the new features that are very
counter-intuitive to me, whether I think in terms of Python or generic
"objects" in any language. The one which gets me the most is the
implicit typing of variables based on the initializer. For basic types
prior to Vim7 (integer and string), you could easily switch the value of
the variable from integer to string or vice versa, and the type() of the
variable would change, suggesting that it behaves like "duck typing" (as
per (wikipedia). But this observation can't be extended to the newer
object types, as the below will fail:
The whole auto-initialize thing is a sticky wicket as far as I see it.
I'd love to have it initialize *all* cases where a name is
references, either on RHS or LHS.
However, I don't know whether this was intended by Bram as a way to
implement type checking.
let a = {}
let a = []
If the type of value determines the type of the variable, and if we are
merely dealing with references (assigning references instead of copying
objects), then why should the second statement above generate the below
error?
E706: Variable type mismatch for: a
Is there a standard for this type of language behavior? I didn't find
anything at this page: http://en.wikipedia.org/wiki/Dynamically_typed
I declare all my script variables before they are used, and it hurts me
for the fact that you have to create an empty array or hash such that
these variable types are established correctly. But when it comes to a
Funcref type, it is lousy that you have to initialize the variable with
the Funcref of some random function so that the type of variable gets
established as Funcref.
I'm not sure I see the problem in practice. The only time you'd have
to pre-define a funcref variable would be if you intended to try to
use it when it was empty. Are you really doing this?
I don't know if what I say above makes sense to anyone (I never studied
computer science, so these are based on what you could call as common
sense of a software developer :), or if anything can be done about them
now, but at least I thought I will give some feedback on what has been
bothering me.
--
Thank you,
Hari
