My understanding of userCan (which may be erroneous) was that the return
value must be a boolean that means semantically "continue hook processing?"
and that the $result var was to contain the result (if any).
It's possible that an implementor of userCan may only be interested in
certain titles, and so returning true with no $result is totally valid.
Consider for example an extension which limits access to User pages -
returning true and not touching &$result would be the correct behavior for
non-User pages.
It would seem to me appropriate to allow $result to be either a boolean or
an array depending on whether the hook is an old implementation or wants to
leverage the new api.
-- Jim
On 7/10/07, Andrew Garrett <andrew(a)epstone.net> wrote:
On 7/10/07, Rob Church <robchur(a)gmail.com> wrote:
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?
Rob Church
--
Andrew Garrett
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/wikitech-l