RE: Call Back information

On Thu, 20 Feb 2003, Bartell, Aaron L. (TC) wrote:
>
> Through your example I am thinking that call backs are directly related to
> procedure pointers and the dynamic routing of procedure calls(it seems that
> way anyway), correct?

That's correct.

That's all callbacks are... you provide a procedure at runtime to be
called.   This is just a way to allow an API/service program to return
many results... it just calls your procedure for each result that it
finds.

You use a procedure pointer to do this because, at runtime, that's all a
procedure is...  executable machine code that's been loaded into memory at
an address...  and, of course, pointers are the type of variable used to
store addresses.

> We build a lot of external service programs that are then bound to
> calling programs and used as needed.  We are looking for ways to utilize
> the call back concept to talk back and forth between sub procedures in
> the service program and in the main calling program.  We have looked at
> using them for error handling, returning data structures to fill
> subfiles, and other uses that follow the same premise.
>
> Does anybody have opinions on when to use call backs and/or anything to
> watch out for?
>

Well, I wouldn't use a callback for error handling...    Usually when you
call a routine in a service program, you want the next line of code to be
able to detect an error.   You don't want some external procedure being
called...

i.e. this is what you want:

     eval rc = myproc(blah: blah)
     if   rc = ERROR
       . . . handle error here
     endif

not this:

     callp    myproc(blah: blah)

     (and then somewhere else in the code)

     p error_handler B
     D error_handler PI
       . . . handle error here
     P               E


The first example ("the good one") is very similar in concept to using
MONITOR or %error, the second example (the "not this" example) is similar
to using *PSSR.


For other things...  maybe.   I use callbacks in both FTPAPI and HTTPAPI
to allow the user to provide his own procedure that handles writing the
received data to disk, or reading the outgoing data from disk.   This
adds flexibility.

http://www.scottklement.com/ftpapi/
http://www.scottklement.com/ftpapi/

On the other hand, most people don't want to understand callbacks, or even
how to read/write stream files.   So, I provide my own callbacks that do
the most common methods of file reading/writing, and a wrapper routine so
that the user doesn't have to supply any.  (This is the difference between
FTP_get() and FTP_getraw() for example... FTP_get simply calls FTP_getraw
and supplies the appropriate callback)

So, complexity of coding is a big factor in when I use or don't use
callbacks.

Another big factor is the "how will this be used" factor.   If a program
is just going to use the callback to load the results into an array, it would
be much easier if you just returned an array to begin with.    Likewise,
if a program is going to just set a flag, and it's going to check that
flag right after calling the procedure...  it makes more sense to just use
a parameter or return value.

On the other hand, if you're filling a subfile, a callback might be nice.
You don't need to waste a lot of memory on an array, etc, just call back
a routine that writes the data directly to the subfile.   If the end of
the subfile is reached, a parameter or return value from the callback
can easily be used to signal the service program that it's out of space
and it should stop calling you back.

That's all I can think of to say right now :)