On 7/3/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
On 7/3/06, Eric Arnold <[EMAIL PROTECTED]> wrote:
> On 7/3/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> > On 7/3/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> > > On 6/30/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
> > > > ... The Funcref obtained via function('s:T') can't be
> > > > called from outside the script ... [unexpectedly]
> > >
> > > I agree, Hari. I'd expect funcref function('s:T') to be callable
> > > outside of the script, too.
> >
> > To make myself more clear. I expect g:Xxx() to be callable
> > from global scope of from another script in this example:
> >
> > " --- scritp x.vim
> > function! s:XXX()
> > echo "func XXX"
> > endfunction
> >
> > let g:Xxx=function('s:XXX')
> >
> > Yakov
> >
>
>
> The problem with this is that you can no longer have private object
> function refs.
Of course you can .:
No. These are variables where you have managed their scopes, but the
underlying func ref *contained* would lose it's ability to maintain
it's scope, i.e. .....
let s:Xxx=function('s:XXX') " script-private funcref
You could do
let g:Xxx = s:Xxx
and now the private/script-local function s:XXX() can be called
globally through g:Xxx . I'm not sure whether this would be a
good or bad thing. It's sort of an ease-of-use vs strict scoping
rules.
Also, I think there might be a semantics problem here about the term
"function reference". It seems to be concurrently the variable name,
which can be called as a function directly, vs the underlying
reference itself. I *think* that the func ref var actually does
contain a reference, rather than *being* a reference, especially since
you can pass it around, and maintain the original function name
Anyway, I think there are, or should be two terms to talk about this
kind of issue:
- function reference
- function reference variable
let l:Xxx=function('s:XXX') " function-private funcref
let g:Xxx=function('s:XXX') " globally-accessible funcref
Yakov
I'm still not sure that I understand the utility of this. If you want
to create a global func ref variable which can call its content, which
is a script-local function ref, then why not just make the function
global in the first place? Are you worried about a global namespace
conflict of the global function [ref] name? I guess the proposed
change/request would allow creating an alias in the form of a global
func ref var, bypass a global namespace conflict.
Detouring away from the namespace question, here are two examples to consider:
let s:obj = {}
function s:obj.tstfunc() dict
return 'here'
endfunction
echo s:obj.tstfunc()
let g:Ref = s:obj
" Yank and put this into the command line to test global scope:
echo g:Ref.tstfunc()
or
function! s:tstfunc2()
return 'here2'
endfunction
let s:ref = function( 's:tstfunc2' )
echo s:ref()
let g:Global_ref = s:ref
" Yank and put this into the command line to test global scope, it should fail:
echo g:Global_ref()
So, my question is: Why should this be allowed? In the above test
script, if you made function('s:XXX') global, then it is true in
your examples, that you can create local function ref variables which
hold that ref. However, in your example,
let g:Xxx=function('s:XXX') " globally-accessible funcref
here you have violated the explicit scope set on the function s:XXX
. Actually, I personally don't care which happens, since I use
scoping in Vim only for namespace separation, not data hiding (where I
think the violation might cause some problem that I can't think of
:-).
Lastly, we've got an inconsistency: dict functions created as
numbered function refs which are always global, vs the above which
maintains scope.
