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
As an Amazon Associate we earn from qualifying purchases.