Talk:Callback (computer programming)
|WikiProject Computing||(Rated Start-class)|
- 1 [Untitled]
- 2 Suggestion
- 3 Example
- 4 Need to keep example code very simple
- 5 The "language extension and adaptation" closure method
- 6 This article is difficult to understand
- 7 Callbacks > Polymorphism??
- 8 User exit?
- 9 Augh!
- 11 Example code now TOO simple
- 12 Example doesn't compile.
- 13 Please disambiguate "predicates"
- 14 Remove rand calls in Example Code?
- 15 function pointers page
- 16 C++11
- 17 Should mention / link to the futures and promises article
This topic needs more general discussion of callbacks and their use, with simpler examples that explain the concept of a callback. I am rewriting most of this article to include much more information. -- Who said this and when? Mattsenate (talk) 01:07, 13 December 2012 (UTC)
I agree that this article needs some rewriting and simpler examples, and I make some suggestions. The long code on the page doesn't help, especially if C is not a language you are familiar with.
As part of a program A, suppose that a procedure or function B is called from A. Normally B would execute completely (perhaps including calls to other procedures/functions C, D ...) before returning control (and results) to A. With callback, A calls B, but passes to B information that allows B to call A2, a procedure or function which is part of the program A (i.e. is included in the code of A). The function of A2 may be to accept some partial results from B which can be passed back to A before execution of B is complete, or to carry out some action in A's environment that B is permitted to control. The implementation of callback is possible by passing procedures/functions as parameters but it is not the only mechanism.
Suggested example: data compression. Main program A wants to compress some data and output the compressed data in some way, such as to a file. Within A, a procedure A2 exists to accept some data and output it to a file. A calls B to pass data for compression and B compresses it, passing compressed data back by callback to A2, as and when it is convenient for B. Notice that this simplifies B, because it does not have to store all the compressed data and pass it back to A, and it also reduces the memory requirement within B, because compressed data that it no longer needs can be passed by callback to A2. However, the final return from B to A does not occur until B itself has determined that its task is finished. When this final return occurs, A knows that all the compressed data has already been output, and only requires to finalise the file output, perhaps by closing the file.
Implementation addition: in Ada, callback can be implemented by the use of generic procedure or function parameters as well as by 'pointers' (called access values in Ada) to procedures or functions passed as parameters.
Sangwine 20:39, 6 September 2006 (UTC)
Well, why these functions return int, when counter assumes they return void?
Why 9 is before 10, in hex?
- Fixed: temporay loss of sanity. Dysprosia 12:50, 15 Dec 2003 (UTC)
Need to keep example code very simple
Ldo, I'm afraid that your changes (on 17 Sep 2004) have really gone farther than needed. This page is now overly complicated and reads more of a disertation on sorting algorithms rather than a simple encyclopedic article on the callback function. I think keeping any example to the minimal possible to show the concept of callback is best, and leave the lengthy programming textbook and best practices explanation elsewhere. Also some of your text is too gramatically casual, especially the paragraphs full of questions. - Dmeranda 06:54, 15 Oct 2004 (UTC)
The "language extension and adaptation" closure method
The article currently gives the following as one way to do callbacks:
- Some systems have built-in programming languages to support extension and adaptation. These languages provide callbacks without the need for separate software development tools.
Can someone turn this into a more concrete claim? What are people thinking of here? LISP macros, perhaps? --Ryguasu 29 June 2005 19:00 (UTC)
This article is difficult to understand
I'm a software engineer (a real one (yeah, I know this is a very inflammatory way to start ;))) and I have difficulties understanding this article. For example, in the Motivation section it is mentioned that the code of the iterator must be duplicated everywhere the list must be iterated over. Why? Are we talking about the machine code (even then, I wouldn't understand why it would need to be inlined) or about the high-level language code? E.g. in Java, when I have to iterate over a Collection, I don't see myself duplicating any code. --184.108.40.206 15:21, 28 February 2006 (UTC)
- Me again. After reading the code examples that come right after, I got it.. we were talking about the high-level language repetition of the "get the iterator/loop until itr.next() returns null" stuff. Maybe it should be made explicit in the text? I'm too slow? ;) --220.127.116.11 15:30, 28 February 2006 (UTC)
Now that I've gotten some distance from it, yeah, it is pretty difficult to understand. It assumes familiarity with many concepts and terms, and the example is somewhat motivated. I've made a note to revise it. Gazpacho 19:48, 30 March 2006 (UTC)
I think what he means is that the entire code block within the loop must be run again each time the index is increased.
Callbacks > Polymorphism??
I don't agree with this passage:
- A callback can be used as a simpler alternative to polymorphism and generic programming, in that the exact behavior of a function can be dynamically determined by passing different (yet compatible) function pointers or handles to the lower-level function.
That's at least misleading. It sounds like it's advocating using function pointers rather than polymorphism because "the exact behavior of a function can be dynamically determined by passing different ... function pointers". Polymorphism and generic programming can do the same thing (at least as well, IMHO). You might be able to argue that function pointers are simpler, buy anyone who has tried to use them in C++ knows that (1) the syntax is horrific and (2) using member function pointers for callbacks is a nightmare. By the way, it may be worth mentioning boost::function somewhere in the article, which is a superb library that uses generic programming to make function pointer-like objects which can be used very effectively for callbacks.
A friend just did a wikipedia search on "user exit" and was brought to this page. They then checked with me as it seemed wrong. I don't agree that a Callback is the same thing as a user exit. At a generic high level a user exit is simply a break in current execution where some 3rd party code or another application is run. I believe the term comes from the need/ability for a user to exit from an application run a command in the shell for example and then return. More commonly now user exits are automatic in that they happen without human intervention where someone wants to execute a script or some code in the middle of something else. A callback is something else entirely (as described correctly in the article)... thoughts? --Bleveret 11:29, 13 March 2007 (UTC)
- I added the term user exit to this article primarily because there was no suitable article for the term. A Wiki search yielded little more than a reference in Exit (command).
- I first heard the term being used by IBM mainframe programmers in the 70s, whereby a user program provided its own versions of predefined subroutines that took the place of the default routines (usually stubs that did nothing but a return) provided by the package/library vendor. Typical usage was in a sort/merge package, which provided user exits for record comparison routines and the like. So by this usage, "user exit" does not quite agree with your definition above.
- I think user exits differ from callbacks in that they are established by the user program not by being passed to a registration function, but by being linked directly into the executable image. Consequently, they must have the names of the routines they are replacing, instead of having any name the user desires. On the other hand, I think they resemble callbacks enough to be relevant to this article.
- Perhaps "user exit" should be a separate section in this article to explain how it compares to a "callback". Or perhaps it should have its own article? In any case, the term "user exit" should point to something informative in Wiki. — Loadmaster 15:01, 13 March 2007 (UTC)
- I think we are in agreement that although similar in some cases the two terms are not synonymous. I have no problem with the redirect but i think the phrase 'a callback (also known as a user exit)' is incorrect. Would you be happy if this phrase was removed and reference was made to the term "user exit" elsewhere in the article? --Bleveret 15:45, 13 March 2007 (UTC)
- Yeah, that would be fine. Like I said, we could simply add a subsection to the existing article. This would allow us to describe the distinction between the two, and perhaps later the subsection could be expanded into its own article. — Loadmaster 20:20, 13 March 2007 (UTC)
I created a short (stub) article for user exit. I also changed the into para of this article, removing the "also called a user exit" phrase, and adding a link to the new article in the "See also" section. — Loadmaster 18:54, 14 March 2007 (UTC)
The second paragraph of this current article is absolutely horrible. 99.999999% of the world doesn't exist in the original author's stream of consciousness. Can someone please translate it from spaz into English? —Preceding unsigned comment added by 18.104.22.168 (talk) 15:43, 31 March 2009 (UTC)
- I agree. I was able to benefit from the example, but it isn't quite encyclopedic. It's kind of unprofessional. I would have loved it if it were in a blog post, but this needs to be as comprehensible as possible, which means simple and dry. If I think of a good way to rephrase the example, perhaps I'll make an edit. 22.214.171.124 (talk) 17:39, 5 April 2009 (UTC)
- i guess i disagree. i checked out this article after reading some gtk+ documentation and i think it makes sense from my perspective. i loved the quirkiness and am glad to see that people can still have a sense of humour when they write something that is helpful. —Preceding unsigned comment added by 126.96.36.199 (talk) 03:26, 7 April 2009 (UTC)
- I rewrote the article to actually talk about callbacks and not handling 2012; also, we cannot have a sense of humor - such things inevitably obscure the content. BioTube (talk) 23:34, 3 June 2009 (UTC)
- Too many platform specific references, ie Linux, Unix. Needs to be abstracted away from punks/hackers prosaic tendencies and their favorite languages and towards compsci academics. —Preceding unsigned comment added by 188.8.131.52 (talk) 04:37, 28 July 2010 (UTC)
sam —Preceding unsigned comment added by 184.108.40.206 (talk) 18:50, 9 July 2009 (UTC) The C signal example is this a good example of where a callback is needed? I've seen in books where a simple function call to a signal handler is used. Also this compiles with a warning:sigtest.c:11: warning: passing argument 2 of ‘signal’ from incompatible pointer type. I don't know C that well but I'm actually trying to get sorted in my head what really differentiates a callback function from a regular call to a function; I'm not sure the signal example does that.220.127.116.11 (talk) 00:28, 15 August 2009 (UTC)
Example code now TOO simple
Example code now doesn't show a function with a callback in it - it presumes the readeer already has some other window open somewhere showing them the prototype for signal(), which is, I feel, not a safe assumption.
I feel that a comprehensive example needs at least three functions: main(), the function that takes the callback as a parameter, and the callback function itself.
It should not assume anything system dependant, nor more than the most basic of knowledge of the language, and even that should be guessable from knowledge of other languages (printf, rand).
Example doesn't compile.
So you know. --fs 07:16, 19 December 2010 (UTC)
- Compiles just fine now (for me, at least). I take it this talk thread could be deleted now. --rs2 (talk) 21:47, 13 July 2011 (UTC)
Please disambiguate "predicates"
Having come to this site to (re)learn about callbacks, I followed the "predicates" link from the following quote and none of the provided definitions really make sense to me here. I guess Branch predication seems like a fairly close fit, but I'm not feeling it. Can someone who understands what was intended provide the disambiguated link? --rs2 (talk) 21:33, 13 July 2011 (UTC)
- Callbacks may also be used to control whether a function acts or not: Xlib allows custom predicates to be specified to determine whether a program wishes to handle an event.
Remove rand calls in Example Code?
Especially for (very) beginner programmers, I feel that the use of rand() calls in the example functions isn't particularly necessary to illustrate how callbacks work, and might serve to unnecessarily confuse, say, a primary-school CS student comparing their program output to the example output listed. I think rand() calls should be deleted from the functions defined in the example, though it could be left in the first line of main() to illustrate that callbacks can be used with already-present functions as well. In the defined functions, simple integer returns should do. Zbbentley (talk) 21:53, 2 August 2011 (UTC)
- I think anyone interested in callbacks will know what rand() does. --Byteality (talk) 16:33, 6 January 2012 (UTC)
function pointers page
A brief discussion of the new std::function<> class, enabled by the recent C++11 addenda to C++ should be in order, don't you think so ? See for instance : 
- To note: std::function objects make it possible to call : 1) a non member function 2) a static member function 3) a functional object 4) a lambda function 5) a non static member function (via std::bind). That is they can refer to any callable entity with compatible signature and are particularly useful to callback.Ptyxs (talk) 08:07, 4 August 2012 (UTC)