On Thu, 19 Jun 2003, Sara Golemon wrote: > > 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....)
Agreed. > Would it make sense to include a table of all callback types? Perhaps with > a list of all their parameters? Probably not.... [snip] How about the callback examples demonstrate one of each type and/or link to an example of each type. > > 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? Davey (and I) meant <type> in general links to the appropriate type pages. So by linking there, callbacks only need explaining in one place (aside from mentioning the accepted types of callbacks). The methodsynopsis is of course immune to this linking. > > 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... I'm for using the type "callback" here as somewhere in the docs there will be a link to the callback type. If someone uses these functions they really should know what callback means and having it as a type in the proto clearly shows it's a callback. Mixed, to me, would mean it can be a callback or something else. Since we list both mixed and callback as psuedo types, we may as well use them both. Not sure the ideal parameter name though, 'handler' sounds decent. Regards, Philip -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
