Re: procedures calling procedure calling procedure...
16/10/2002 9:34:51 AM, petelomax at blueyonder.co.uk wrote:
>I've bit my tongue on this, apparently too long.
>Just what, exactly, is *SO* hard about
>
>global integer closeCompareRID
>...
> call_proc(closeCompareRID, {})
>...
>procedure closeCOMPARE()
>closeCompareRID = routine_id("closeCOMPARE")
>
>
>over & above:
>
> closeCOMPARE()
>...
>procedure closeCOMPARE()
>
>?????
>Yeah, two extra lines and some syntax, SO? Just how often do you
>actually use forward references anyway?
Hi Pete,
there is nothing hard about using routine_id. My issue is not that routine_id is
hard to use or even
is a poor work-around. In fact, routine_id is an excellent addition to the
language and I would be
very sad if it ever went away. It is also an excellent work around for the lack
of forward
referencing. It adheres to the feel of Euphoria well (except that it uses
zero-based indexing
whereas Euphoria generally uses one-based indexing).
My problem is that the physical location of the routines in a source file has no
relation to their
functional grouping, thus I should be able to physically group together routines
that are logically
related. However, this is not always possible with Euphoria. Euphoria can force
logically related
routines to be physically seperated due to the need of the interpreter to parse
a routine's source
code before that routine can be referenced.
In small programs this is not a big deal. But when dealing with large source
files, I am often
having to rearrange the location of routines when adding new calls. Well I used
to. I've given up
doing this now and resorting to routine_id() calls instead, thus increasing the
calling overhead of
the routine.
I'm not arguing that it is difficult to use routine_id. I'm arguing against the
need to rearrange
existing source code just because I've added a new call reference.
>I, for one, possibly lone voice, appreciate that the former clearly
>signals to me, the human reader, that closeCOMPARE() has not yet been
>defined; I haven't missed it; it may not even be in this source.
>(which is true anyway for global routines of include files)
I can appreciate this point of view, Pete. With the current Euphoria, you always
know that a routine
being referred to is somewhere earlier in the source file. It doesn't mean that
it actually exists!
But if it does, it's line number is less than the current line.
However, just because you might see "call_proc(closeCompareRID, {})", does not
mean that
closeCompare is definitely not yet defined, nor does it mean that
closeCompareRID is initialized,
nor does it mean that closeCompareRID has been initialized with routine_id of
"closeCompare".
>Derek, I am frankly amazed that you bear such a grudge on this issue
Frankly Pete, so am I! I'm not normally given over to passionate opinionating.
And I'm very sorry if
this is a waste of bandwidth. However, I refuse to believe that Euphoria is as
good as it can be. It
is only with public debate that this community can weigh the merits (or lack
thereof) of
individual's opinions.
>as surely if this had been in the language from the get-go then
>routine_id() would not exist and your work on win32lib would basically
>be nigh impossible?!
Again, I'm not complaining about routine_id. I truely believe that routine_id()
is one of Euphoria's
great strengths. Not only does win32lib depend on this functionality, but many,
many Euphoria
programs do. I just wish I could freely add new calls to Win32lib without having
to worry about
rearranging the code to stop Euphoria complaining. It really wouldn't take much
more smarts in the
interpreter to automatically insert call_proc/func() in cases where the called
routine exists and it
is defined starting on a line number greater than the "call" line.
>Pete
>PS Rob, routine_id("rubbish") currently returns -1 (assuming of course
>that no procedure or function rubbish has been defined).
>
>What chances of an error/warning message instead?
>
>I feel a minor spelling mistake can cause major headaches in this
>case.
Not a bad idea, so long as this can be turned on and off using a "with"
directive. Win32lib and some
O-O schemes rely on a -1 being returned sometimes.
---------
Cheers,
Derek Parnell
|
Not Categorized, Please Help
|
|
