Re: Callback

Allow me to present another example from the system APIs - I just remembered this one -

There is an API that walks through IFS files and directories -


Qp0lProcessSubtree().

Now here's where things get murky - When you call this, you specify a path and some inclusion criteria - and either the name of a program or address of a procedure - and the documentation calls this an exit program - it smells to me like what I think of as a callback - sheesh!!

But that's the idea - you call some API - you give it a way to call whatever functionality YOU want it to do when the API finds an object - this is similar to the procedure you tell qsort(0) about, which gets called for each element in the data to be sorted.

I think I see a callback as connected to a repetitive process, while an exit program is a one-time thing - but THIS API doc uses the term "exit" for the repetitive event kind of thing.

Now another API is readdir() - this one returns a structure for the NEXT item it finds in the directory - so YOU have to run this in a loop until no more objects are found. The first API itself contains the processing loop - that first API seems to fit the idea, again, of the use of callback functions or programs. Pretty neat!

Uffda! Norwegian for a feeling of sensory overload! Pronounced as Ooph-dah!

Vern

On 10/17/2012 11:31 PM, Evan Harris wrote:

I think the key thing to take away is that a call back is where a
procedure or function is passed into another routine as a parameter,
and that the passed-in routine is to be called back for each element
or item selected or read in the called routine.

The scenario where I've used callbacks (and I've not done them in RPG)
is where I have a process that reads or scans through an arbitrary
list of objects and I want to be able to do different things to them
or with them, sometimes based on the value of the object itself.

Consider where I have a customer list and I want to do something to
each customer. I can copy the code to read the customer list and
create a new program to call the function I need, or I can make the
code to read the customer list a little more generic and then pass a
pointer the function I want performed on each customer into the
routine that "knows how" to read the customer list. So long as I code
the routine to be called back in a common way I can easily add new
functions to the read customer routine simply by varying the call back
function I pass into the read customer routine.

Depending on how often or how dynamic what might happen to the
customer object is (in my example), using a call back might be a whole
lot simpler than creating multiple programs or options in the read
customer routine.

It seems to me that callbacks might be a little more suited to event
driven processing - maybe that's why they are not so widely known
about in the IBM i world.


On Thu, Oct 18, 2012 at 1:15 PM, Vernon Hamberg
<vhamberg@xxxxxxxxxxxxxxx> wrote:

John

As I wrote my reply, I was thinking about whether we can specify the
address of a procedure in another service program, say. I didn't bring
it up, because I wasn't sure, and I thought it'd confuse the issue.
Generalizing to that would have benefits similar to what we espouse
already for service programs.

I'll still go with the callback term - I could even say that the called
party is calling back to someone known to the calling party. It does
seem to get a bit precious, however, and the traditional understanding
works for me, although I hear what you are saying.

Vern