On 7/10/07, Rob Church robchur@gmail.com wrote:
On 10/07/07, Andrew Garrett andrew@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?
Rob Church