Re: routine_id() Discovery
Matt Lewis wrote:
> c.k.lester wrote:
> > But, if I add the routine_id() of myfunc() to a global list, then I can
> > call it from myprog.e with call_func().
> Or add it to some local variable in myprog.e through some routine like, say,
> myprog:set_event_handler().
Well, what I'm actually doing is having the included file with the function
call an add_func( "routine_name", routine_id("routine_name") ) which adds
the routine info to a list (the list is not global).
Then later it can be called with
call_func( a_routine(a), {} )
> > That means it can be exported but not made global... right?
> Yes, but in an annoying way [for most purposes]. call_func/proc don't care
> about scope.
That explains the behavior, I guess. They don't care about scope. :D
It just seems funny to me that I have access to a non-global function from
where it's not in the global space.
I got to this point, though, because some funcs/procs weren't being seen
anymore by the calling code. I mean, I had
call_func( routine_id("a_global_func"), {} )
that wasn't able to find a_global_func(). But, I'm dealing with over 40
include files and I threw my hands in the air and just decided to add all
the functions to a global list instead of trying to manage the include
files (put them in proper order). grrrrrr.
So, the best solution is for me to ensure that all my funcs/procs are in nice
order and sort my include requests appropriately... but until such time, I'm
just going to have to use this work-around... although, it might be better
this way since now I don't expose the funcs/procs to other libs (by using
'global'), just to the main calling program.
What I need is for some guru (or two) to look over my code and tell me
where things can be done better. Any volunteers? 8)
|
Not Categorized, Please Help
|
|
