OpenEuphoria

Re: routine_id() Discovery

• Posted by Mike <vulcan at w?n.co?nz> May 21, 2008
• 642 views

Hi CK,

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

Here's a radical idea. Why not consider using Orac for your project.
Admittedly, it's a bit disobedient at times (by, well, crashing) but it can
encapsulate like nothing else (in the Euphoria world). 40 include files?
No problemo. Of course, you have to convert the app (by adding more include
statements) and once you do it's difficult to go back, though, would you want
to?

As an enticement, I'll happily do the conversion (should take about an hour)
but you'll need to actually maintain the program. The use of routine_id reduces
vastly under Orac since forward routine calls are possible. Even when routine_id
has to be used, instead of call_func/call_proc you can use the variable itself
in a calling format, eg:

int a = routine_id(..

// Euphoria
call_proc( a, {})

// Orac
a()

You can use dot notation for sequence access too so accessing a stable of
routine ids is a piece of cake. Eg:

seq op
...

op.class.item(whatever) // voila!

kind regards,
Mike


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