1. Re: Forward Definitions
Not to flame, or to get flamed, but how come no one complains about
define_c_func() and define_c_proc() returning a -1 when a C proc/func
doesn't
exist?
Just my 2ยข
Austin (aka The AfterBeat)
"Cuny, David" wrote:
> Rod Jackson wrote:
>
> > David continues...
> >
> >> I'd much rather change the behavior to:
> >>
> >> 1. Disallow routines in the same scope to be redefined.
> >> 2. Have built-ins return valid routine id's.
> >
> > Interesting. I assume you're advocating the ability to redefine
> > ANY routine?
>
> I'm not really in favor of it, but Gabriel (and others) have found it
> useful. If it continues as a feature, it should at least be consistant.
>
> > As far as I can tell, routine_id DOES look up and return
> > IDs at run-time...
>
> You misunderstand my complaint here. While the code executes at run time,
> the scope of routines that it sees is limited to that which it could see at
> complile time. For example:
>
> procedure foo()
> ? routine_id("bar")
> end procedure
>
> procedure bar()
> end procedure
>
> foo()
>
> will produce:
>
> -1
>
> even though 'bar' is defined before the point which foo is called. That's
> because the scope of the routines that foo can see is defined by where it
> was coded (before bar) and not where is run (after bar).
>
> > And I was fairly surprised when I first found out 0 was a valid
> > routine ID. I don't see it as being much of a bother, except that
> > it doesn't seem to fit neatly ...
>
> Exactly. All other routines in Euphoria return 0 for false; it seems strange
> that this one doesn't as well.
>
> -- David Cuny
