1. 3.0 feature request: nested calls
Something else not mentioned, which is a little nicety, is nested
functions/procedures within other functions/procedures. This is like Eu's
include files with local scoping within those files. The upsides to allowing
this
is total lack of namespace conflicts, and inherently tight variable scope.
procedure1()
--var list here
-- no code allowed here
function2()
-- uses it's own
or procedure1's vars
or main globals
end function2
-- no code allowed here
procedure3()
-- uses it's own
or procedure1's vars
or main globals
end procedure3
-- procedure1 code here
-- can call function2
or procedure3
or any other normal call
end -- procedure1
Like i said, procedure1 can be moved to an include.e, with function2 and
procedure3 local to that include.e file. It's just a thought. Possibly the scope
methods could treat the nested system a little differently <shrug>. I found
apps ran faster if i used vars local to procedure1 with function2 and
procedure3, rather than passing anything when i called them, and this
nesting guaranteed nothing leaked from procedure1.
Kat
2. Re: 3.0 feature request: nested calls
Kat wrote:
>
> Something else not mentioned, which is a little nicety, is nested
> functions/procedures within other functions/procedures. This is like Eu's
> include files with local scoping within those files. The upsides to allowing
> this
> is total lack of namespace conflicts, and inherently tight variable scope.
>
>
> procedure1()
> --var list here
> -- no code allowed here
>
> function2()
> -- uses it's own
> or procedure1's vars
> or main globals
> end function2
>
> -- no code allowed here
>
> procedure3()
> -- uses it's own
> or procedure1's vars
> or main globals
> end procedure3
>
> -- procedure1 code here
> -- can call function2
> or procedure3
> or any other normal call
>
> end -- procedure1
>
> Like i said, procedure1 can be moved to an include.e, with function2 and
> procedure3 local to that include.e file. It's just a thought. Possibly the
> scope
> methods could treat the nested system a little differently <shrug>. I found
> apps ran faster if i used vars local to procedure1 with function2 and
> procedure3, rather than passing anything when i called them, and this
> nesting guaranteed nothing leaked from procedure1.
>
> Kat
>
>
What I think you really want is a better inclusion system.
Regards, Alexander Toresson
3. Re: 3.0 feature request: nested calls
> Date: Fri, 15 Jul 2005 12:19:51 -0500
> From: "Kat" <gertie at visionsix.com>
> Subject: 3.0 feature request: nested calls
>
>
> Something else not mentioned, which is a little nicety, is nested
> functions/procedures within other functions/procedures. This is like Eu's
> include files with local scoping within those files. The upsides to allowing
> this
> is total lack of namespace conflicts, and inherently tight variable scope.
>
I suggested it in the wish list I had posted in Aug. 2002, and still
strongly support it.
CChris
>
> procedure1()
> --var list here
> -- no code allowed here
>
> function2()
> -- uses it's own
> or procedure1's vars
> or main globals
> end function2
>
> -- no code allowed here
>
> procedure3()
> -- uses it's own
> or procedure1's vars
> or main globals
> end procedure3
>
> -- procedure1 code here
> -- can call function2
> or procedure3
> or any other normal call
>
> end -- procedure1
>
> Like i said, procedure1 can be moved to an include.e, with function2 and
> procedure3 local to that include.e file. It's just a thought. Possibly the
> scope
> methods could treat the nested system a little differently <shrug>. I found
> apps ran faster if i used vars local to procedure1 with function2 and
> procedure3, rather than passing anything when i called them, and this
> nesting guaranteed nothing leaked from procedure1.
>
> Kat
>
>
> -----------
