1. What's the Best Way?
- Posted by cklester <cklester at HOTPOP.COM> Jun 15, 2000
- 516 views
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?
- Posted by Brian Broker <bkb at CNW.COM> Jun 15, 2000
- 468 views
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?
- Posted by Matthew Lewis <MatthewL at KAPCOUSA.COM> Jun 15, 2000
- 497 views
> 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
- 561 views
- 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?
- Posted by Brian Broker <bkb at CNW.COM> Jun 16, 2000
- 506 views
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