> Once that was done, I said that this should be referenced wherever > callbacks are used, to keep it all uniform and neat, rather than each > function that uses callbacks either having a copy and paste or a > completely new piece of text on callbacks. > Absolutely, language.types.callback (as opposed to merely language.types) should be directly linked from any function which expects a callback. Of course, any function which uses a callback still needs to specify what parameters their callback expects since each is unique (sorting comparisons tend to be two, shutdowns tend to be none, user error is four or so, context notifier is at least six, etc....)
Would it make sense to include a table of all callback types? Perhaps with a list of all their parameters? Probably not.... I was about to mention that call_user_func was inappropriately named call_user_function, but it seems betz already caught that a couple weeks ago. Frequent docbuilds would be ever so swell.... > At this point, philip said that I should be using <type>callback</type> > in the documentation and that it would link dynamically... fair enough, > In what manual build do prototypes link to the used/returned types automatically? > As you can see, one is using <type>callback</type> the other > <type>mixed</type>, the reasons being obvious - a callback is just a > string or an array... so the question here is, do we respect the > callback type as its own which consists of 'mixed' data, or do we use > mixed? I personally feel that callback is more descriptive. as I am > going through all callback functions anyways, I will change them all to > have the same, whatever is decided. I'm not entirely bothered which is > chosen, so long as one is, and its stuck too. > I say mixed to avoid confusing the user with protos like: somefunc(callback callback); Of course, if all uses of 'callback' as a parameter name were changed to something else (and no not 'function') then I'd be okay with the use of 'callback' as a type. 'userfunc' or 'handler' sound okay... -Sara -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
