Loading ...
Sorry, an error occurred while loading the content.

71132Re: Funcref and script local functions

Expand Messages
  • Hari Krishna Dara
    Jul 8, 2006
    • 0 Attachment
      On Sat, 8 Jul 2006 at 3:10pm, Bram Moolenaar wrote:

      > Hari Krishna Dara 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.
      > The whole purpose of script-local functions is that they will only be
      > used locally in the script. Thus they can't be called from outside the
      > script (without the trick to obtain the script nr). Also not when using
      > a Funcref.

      I often provide public functions that are useful for other plugins to
      interface, so I don't like mixing them up with the functions that are
      not really meant for getting called directly. Can the support for
      calling the script local functions from outside using SNR form be ever
      dropped? If not, I don't mind using this form to keep my plugin
      interface clean, as a workaround (I actually use this trick all the
      time, but always wondered if this is a feature or a bug, and in case it
      is a bug, if it ever will be fixed).


      > > What is weird is that the the Funcref() actually behaves exactly like
      > > the function name itself.
      > Yes, that basically sums it up.
      > > 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 don't know if there is a standard and generally I don't care. There
      > is nothing against inventing something new. The main point is that it's
      > very easy to make mistakes with using the wrong type for a variable.
      > Using declarations is the normal way to have the compiler or interpreter
      > check the type. But declarations are annoying and certainly don't fit
      > with Vim 6.x script. Therefore I used the "sticky types" mechanism: the
      > first time a variable is assigned a value that's the type it has. Very
      > simple and efficient. You just need to remember that variables are not
      > dynamically typed. Except for int/string, for backwards compatibility.

      Do You Yahoo!?
      Tired of spam? Yahoo! Mail has the best spam protection around
    • Show all 12 messages in this topic