Re: Callback

[Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>]

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