1. What's the Best Way?
I've got a big project I'm workin' on, and I've come across a question for
which my experience cannot yet provide a reliable answer... so, I'm throwing
it out here:
I'm creating an include file to help me with data management. Right now I am
accessing the include's procedure with abc( COMMAND , Parameters ), where
abc is the procedure, COMMAND is the particular command, and Parameters is a
sequence containing the parameters for the COMMAND. (Duh, right? 
)
Right now, any output is automatically sent to a global variable, abcOutput,
for the programmer to parse himself.
It goes something like this:
abc( GET_DATA , { recID, field } )
and abcOutput would contain the data returned by that command.
But would it be better for me to make individual procedures/functions?
Instead of
abc( GET_DATA , {recID, field} )
I would use
abc_get_data( recID , field )
or turn it into a function,
abcOutput = abc( GET_DATA , { recID , field } )
or
abcOutput = abc_get_data( recID , field )
Right now it has, maybe, 10 commands, and is handled like this:
procedure abc( sequence command , sequence params )
if command = COMMAND_ONE then...
if command = COMMAND_TWO then...
etc...
end procedure
What's the most efficient way? I'm thinking about cross-platform
compatibility, maintainability, extensibility, etc-bility...
Thanks for your input!
<\<
2. Re: What's the Best Way?
On Thu, 15 Jun 2000 13:03:51 -0500, cklester wrote:
>I've got a big project I'm workin' on, and I've come across a question for
>which my experience cannot yet provide a reliable answer... so, I'm
>throwing it out here:
>
>I'm creating an include file to help me with data management. Right now I
am
>accessing the include's procedure with abc( COMMAND , Parameters ), where
>abc is the procedure, COMMAND is the particular command, and Parameters is
a
>sequence containing the parameters for the COMMAND. (Duh, right? )
>
>Right now, any output is automatically sent to a global variable,
abcOutput,
>for the programmer to parse himself.
>
>It goes something like this:
>
> abc( GET_DATA , { recID, field } )
>
>and abcOutput would contain the data returned by that command.
>
>But would it be better for me to make individual procedures/functions?
IMO, I would say yes, break it into individual functions. My personal
prefence is to avoid global variables when they are not necessary. If you
are using one procedure 'abc' to perform any given number of commands, you
are likely to lose some speed doing a bunch of 'if...then's to figure out
what the command was. Plus, you are going to end up with one huge
procedure that will be difficult to maintain later on. If you are doing it
that way because there is some shared code for all possible commands, just
make that shared code a private routine (accessible only by your library).
-- Brian
3. Re: What's the Best Way?
> From: cklester
>
[snip]
> Right now, any output is automatically sent to a global
> variable, abcOutput,
> for the programmer to parse himself.
>
> It goes something like this:
>
> abc( GET_DATA , { recID, field } )
>
> and abcOutput would contain the data returned by that command.
>
> But would it be better for me to make individual procedures/functions?
> Instead of
> abc( GET_DATA , {recID, field} )
> I would use
> abc_get_data( recID , field )
> or turn it into a function,
> abcOutput = abc( GET_DATA , { recID , field } )
> or
> abcOutput = abc_get_data( recID , field )
> Right now it has, maybe, 10 commands, and is handled like this:
>
> procedure abc( sequence command , sequence params )
> if command = COMMAND_ONE then...
> if command = COMMAND_TWO then...
> etc...
> end procedure
Yuk.
>
> What's the most efficient way? I'm thinking about cross-platform
> compatibility, maintainability, extensibility, etc-bility...
>
I've had to do some things like this. The final solution really depends on
how the commands will be used, but I think your best bet is probably to use
routine_id / call_func to access your commands. This means turning your
procedures into functions, first off. Then, I'd put all of your
routine_id's into a sequence:
COMMAND[1] = routine_id("Command1")
... etc
You can wrap this if you like, with one global procedure (and leave the
actual functions within your include local):
global function DataCommand( integer command, sequence params )
return call_func( command, params )
end function
This has the nice feature of getting rid of the if..then tree you've
constructed, and it's fairly easy to see what's going on. BTW, this is the
same type of thing David Cuny's done in win32lib with event procedures.
<plug>For another example, you can check out my matheval lib at
http://members.xoom.com/matthewlewis/projects
Pretty much everything follows this format, and made much of it work almost
like magic (at least as far as putting together all of the differnt ops was
concerned:).</plug>
Hope this helps.
Matt
4. Re: What's the Best Way?
- Posted by "C. K. Lester" <cklester at HOTPOP.COM>
Jun 15, 2000
-
Last edited Jun 16, 2000
Thanks Brian B and Matthew L!
Your input is helpful. I figured the "routine_id" route would be the best
way to go, but I had already gone this route and wanted to get the ideas in
concrete before changing the paradigm. Did I say that right?
Anyway, thanks, again, for your input. I'm going to start converting the
stuff to functions, then I'll figure out how to use the routine_id stuff. Is
the routine_id stuff crossplatform? For some reason, I thought that stuff
was Win32 only...?
Thanks!
<\<
5. Re: What's the Best Way?
On Thu, 15 Jun 2000 22:11:39 -0500, C. K. Lester wrote:
>Thanks Brian B and Matthew L!
>
>Your input is helpful. I figured the "routine_id" route would be the best
>way to go, but I had already gone this route and wanted to get the ideas in
>concrete before changing the paradigm. Did I say that right?
>
>Anyway, thanks, again, for your input. I'm going to start converting the
>stuff to functions, then I'll figure out how to use the routine_id stuff.
>Is the routine_id stuff crossplatform? For some reason, I thought that
>stuff was Win32 only...?
'routine_id' is platform independent but in my experience is really only
necessary in situations where your library needs to call a routine provided
by a user of the library (a situation where your library does not know what
the function is). This is why it's frequently used in Win32lib. Win32lib
calls event functions that are provided by the user (onOpen, onPaint,
onMouse, onClick, etc.). If your library does not need to use routines
created by the user (routines defined later in the program) then you should
not need to use it. Simply define the functions that the user can access
as 'global'. Routines that are intended to be used only by the libary
(e.g. helper routines that might be used by more than one global routine)
should *not* be declared 'global'.
Hope this clears things up if you weren't too sure about it. Check the
reference manual on 'routine_id' for other possible uses (which includes a
link to a comprehensive discussion of 'scope' in section 2.4.2).
Good luck,
Brian
