On Fri, 20 Jun 2003, Philip Olson wrote:
> 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.
Why not just define a functionsynopsis for them all? AFAIK that's done a
few times too...
> 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.
Right, I' go for "callback" as type too.
Derick
--
"Interpreting what the GPL actually means is a job best left to those
that read the future by examining animal entrails."
-------------------------------------------------------------------------
Derick Rethans http://derickrethans.nl/
International PHP Magazine http://php-mag.net/
-------------------------------------------------------------------------
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
