1. Question for Rob ( Name Space Idea)
Why couldn't you allow procedures be nested in functions. It doesn't seem
like it would be any more difficult than parsing nested IF THEN statements.
Then we could have locally scoped procedures within a Function.
( I don't think you could do this because of all the problems with parsing
function returns )
We could then write something like the following :
----------------------------------------------------------
function scope1(integer proc_to_use, sequence parmeters)
sequence ret_stuff
if proc_to_use = 1 then
local_proc1(sequence parmeters)
elsif
local_proc2(sequence parmeters)
else
local_proc3(sequence parmeters)
end if
return ret_stuff
procedure local_proc1( sequence parameters )
ret_stuff[1] = parameters[1]+parameters[2]
end procedure
procedure local_proc2( sequence parameters )
ret_stuff[1] parameters[1]+parameters[2]-17
ret_stuff[2] parameters[1]*parameters[2]
end procedure
procedure local_proc3( sequence parameters )
ret_stuff[1] parameters[1]+parameters[2]+parameters[3]
ret_stuff[2] parameters[1]*parameters[2]\parameters[3]
end procedure
end function -- scope1
-------------------------
Then you can call any procedure in scope1 but they are out of
scope to your main program ( scope1 would be its namespace )
I think this would be very easiy for you to implement and
It would solve a lot of problems for everyone.
Thanks Bernie
2. Re: Question for Rob ( Name Space Idea)
Bernie Wrote:
Here, I think this does the same thing and still goes
by the current rules:
---------This would be in an *.E file ---------
procedure local_proc1( sequence parameters, sequence ret_stuff)
ret_stuff[1] = parameters[1]+parameters[2]
end procedure
procedure local_proc2( sequence parameters, sequence ret_stuff)
ret_stuff[1] parameters[1]+parameters[2]-17
ret_stuff[2] parameters[1]*parameters[2]
end procedure
procedure local_proc3( sequence parameters, sequence ret_stuff)
ret_stuff[1] parameters[1]+parameters[2]+parameters[3]
ret_stuff[2] parameters[1]*parameters[2]\parameters[3]
end procedure
function scope1(integer proc_to_use, sequence parmeters)
sequence ret_stuff
ret_stuff = {blah, BLAH}
if proc_to_use = 1 then
local_proc1(sequence parmeters, ret_stuff)
elsif
local_proc2(sequence parmeters, ret_stuff)
else
local_proc3(sequence parmeters, ret_stuff)
end if
return ret_stuff
end function -- scope1
----------------------END CODE----------------
I know this isn't EXACTLY the same thing but you'll notice
that the procedures are local to the *.E file and cannot
be called from any other file including your main *.ex file.
Hope this helps,
Lewis Townsend
_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com
3. Re: Question for Rob ( Name Space Idea)
Thank You for your response
I don't think your solution is the same.
I would like Rob's answer to my question.
Thanks again
Bernie
4. Re: Question for Rob ( Name Space Idea)
Bernie Ryan writes:
[why not support nested procedures/functions to
alleviate namespace conflicts?]
I've used languages such as Pascal, Ada, PL/I etc.
that support nested routines, and I've used languages
such as C and others that don't. I've never felt that
nesting buys you very much. It just makes
the scope rules harder to understand, and sometimes
makes the code harder to read, since you may have to
do a lot of scrolling up/down in the editor to figure out
the nesting structure of a large chunk of code.
If you want to make some routines invisible to the rest
of the program, put them in a .e file as Lewis Townsend
suggests.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
5. Re: Question for Rob ( Name Space Idea)
- Posted by Bernie Ryan <bwryan at PCOM.NET>
May 14, 1999
-
Last edited May 15, 1999
Rob you wrote:
>> I've used languages such as Pascal, Ada, PL/I etc.
>> that support nested routines,
>> and I've used languages
>> such as C and others that don't. I've never felt that
>> nesting buys you very much. It just makes
C has reasonable scoping rules.
C++ has NAMESPACES and good scoping rules.
I think that you are writing Euphoria in Watcom C++ which has
good scoping rules so you may be losing your perspective. You
may not realize how difficult it is to write a complicated program
in Euphoria because you are looking at it as an interpter. Ask
some of the game programmers what they think about Euphoria Scoping.
>> the scope rules harder to understand, and sometimes
>> makes the code harder to read, since you may have to
>> do a lot of scrolling up/down in the editor to figure out
>> the nesting structure of a large chunk of code.
Euphoria code is harder to read because you have to look in
all of the .e files. which is a lot harder than scrolling up
and down in a file.
>> If you want to make some routines invisible to the rest
>> of the program, put them in a .e file as Lewis Townsend
>> suggests.
NAMESPACES or Good SCOPING RULES should be supported in any modern
langauge.
PS -- I hope you don't terminate my license because I disagree with you.
Thanks Bernie
