OpenEuphoria

Re: routine_id() Discovery

• Posted by ChrisBurch3 <crylex at ?ma?l.com> May 21, 2008
• 762 views

c.k.lester wrote:
> 
> 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.

coughforwardreferincingcough

> 
> 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)