1. routine_id() Discovery
Maybe this is common knowledge, but I just discovered this...
A routine doesn't have to be global in order to call it from what would
otherwise require a global definition.
For example, this would normally fail:
-- mylib.e
func myfunc()
end func
-- myprog.e
x = myfunc()
with myfunc() is not defined (I think).
But, if I add the routine_id() of myfunc() to a global list, then I can
call it from myprog.e with call_func().
That means it can be exported but not made global... right?
2. Re: routine_id() Discovery
c.k.lester wrote:
>
> Maybe this is common knowledge, but I just discovered this...
>
> A routine doesn't have to be global in order to call it from what would
> otherwise require a global definition.
>
> For example, this would normally fail:
>
> -- mylib.e
> func myfunc()
> end func
>
> -- myprog.e
> x = myfunc()
>
> with myfunc() is not defined (I think).
>
> But, if I add the routine_id() of myfunc() to a global list, then I can
> call it from myprog.e with call_func().
>
> That means it can be exported but not made global... right?
This turns a global function into a global variable to hold or pass the
routine_id. Great. It still needs being hidden.
CChris
3. Re: routine_id() Discovery
c.k.lester wrote:
>
> Maybe this is common knowledge, but I just discovered this...
You already knew about this, but you didn't realize it...
> A routine doesn't have to be global in order to call it from what would
> otherwise require a global definition.
>
> For example, this would normally fail:
>
> -- mylib.e
> func myfunc()
> end func
>
> -- myprog.e
> x = myfunc()
>
> with myfunc() is not defined (I think).
>
> 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().
> 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.
Matt
4. 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)
5. Re: routine_id() Discovery
- Posted by Matt Lewis <matthewwalkerlewis at ?mail.co?>
May 21, 2008
-
Last edited May 22, 2008
c.k.lester wrote:
>
> It just seems funny to me that I have access to a non-global function from
> where it's not in the global space.
Yeah, well, like I said, if you've been using win32lib or wxEuphoria, you've
been doing this forever. :)
Matt
6. Re: routine_id() Discovery
- Posted by ChrisBurch3 <crylex at ?ma?l.com>
May 21, 2008
-
Last edited May 22, 2008
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)
7. Re: routine_id() Discovery
- Posted by Mike <vulcan at w?n.co?nz>
May 21, 2008
-
Last edited May 22, 2008
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)
8. Re: routine_id() Discovery
- Posted by c.k.lester <euphoric at ckl?ster?com>
May 21, 2008
-
Last edited May 22, 2008
ChrisBurch3 wrote:
> c.k.lester wrote:
> > 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
I believe in the no-forward-referencing paradigm. :)
But I don't believe in quoting entire messages for one line of text. :P
9. Re: routine_id() Discovery
Mike wrote:
>
> > 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.
I don't know enough about Orac to even begin to consider it. :)
I don't even know what an optimizing incremental x-compiler is!
I'll download it and check it out.
