On 10/07/07, Andrew Garrett <andrew(a)epstone.net>
wrote:
Hooks will be allowed, but not required, to
follow the new convention.
As always, possible responses will be 'true' for "yes", 'false'
for
"no", or 'null' for "no opinion". Of course, the hook will
still be
allowed to return an answer with the new array syntax.
That isn't how hooks work, however; the userCan hook always has been
somewhat broken in this respect.
A hook must return a boolean, which indicates whether or not the
standard process to complete an operation should proceed; this boolean
is also responsible for allowing the rest of the hook chain to
complete. For example, an authentication hook would usually return
false, to prevent later, more lenient hooks, from overriding it.
To pass more meaningful results into the caller, we generally use the
good old-fashioned, C-style method of passing a reference (no
pointers) to a variable which should contain the result. This could be
a boolean, or it could be null, as you describe.
I stand corrected. What is your suggestion with respect to this, then?
Break backwards-compatibility and require the hook to accept a
variable reference to fill with its response (true, false, null or an
array), create a new hook, retaining the previous one for the sake of
backwards-compatibility, or something different?