On Mon, Oct 15, 2012 at 5:46 PM, Vernon Hamberg
<vhamberg@xxxxxxxxxxxxxxx> wrote:
The easiest example I use - the almost-only-one, actually, is when I use
the qsort API - when you call qsort, you tell it what data is to be
sorted, how long each element is, and a pointer to a procedure that will
compare 2 elements and return either that they are the same or that one
or the other is larger. That procedure is the callback - maybe we can
think of it as a CALL BACK to the caller of qsort. qsort walks through
the elements and passes pairs of them to the callback procedure.
I have never really liked the explanation that the called function is
"calling back" to the original caller. Yes, that's where the term
came from, but I don't think it emphasizes the right things.
When people talk in those terms, it sounds like there are TWO distinct
parties: (1) calling code and (2) called code. The calling code
provides the "callback function" as a parameter to the called
function. This explanation implies the callback function "belongs to"
or "is a part of" the calling code. And in a way it (usually) is,
because the calling code is (usually) in one source member, and that
source member (usually) does contain the code for the callback
function. And I suppose the called code is often in another member.
(See the picture in the Wikipedia entry[1] for what I mean. They have
a box called "application program" and a box called "software
library". The application program calls the software library, which
"calls back" into the application program.)
To me, this is not the best way to think about it. I like to think of
it as THREE distinct parties: (1) a caller (or calling function), (2)
a called function, and (3) a callback function. We are really talking
about three functions (I'm going to use the term function because
that's the term used by most languages). The callback function must
be *known* to the caller (otherwise how would the caller pass it to
the called function?) but there is no reason to think of it as
belonging to or being a part of the caller. In some cases it can be,
but it's often not, so I'd recommend thinking of the callback function
as its own, separate beast, that happens to be known to the original
caller. And frankly, I would recommend not really thinking too hard
about what "calling back" means. It's really JUST ANOTHER FUNCTION,
and it happens to be passed as a parameter from the calling function
to the called function.
So again, the Wikipedia picture[1] provides some context. I think
about those ovals, not about the enclosing boxes.
Now, it can be the case, especially in dynamic languages like
JavaScript and most other scripting languages that you may have heard
of, that the caller is actually creating the callback function on the
fly, at run-time. This might seem like craziness from a traditional
RPG standpoint, but as Scott mentioned, it's all over the place in
JavaScript.
I'm probably stepping out on a limb - maybe one can look at it as a kind
of exit program. That's a user-defined program called at some point in a
system or application process. Close enough definition, I hope!
I don't think this is a bad limb to be on. It's another example
mentioned by Scott, and I think it's a useful way to think about it
for people who are comfortable with exit programs but not too familiar
with JavaScript.
John
[1]
http://en.wikipedia.org/wiki/Callback_%28computer_programming%29
midrange.com
