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')
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:
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 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
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
