There are times when killing the stack is intended. It doesn't have to be "null" per se - but something that resolves to false in a PHP boolean context. One example (off the top of my head) would be "userCan". Say you're writing an extension that's supposed to limit access to something. It may be your extension's intent to set the $result to false and then actually return false so no other more lenient extension has a chance to display the protected resource. There are other cases I've run into, but I'd have to look in the codebase for them. Pretty much whereever you see something like this: if ( !wfRunHooks( 'SomethingOrOther', array( &$this, &anotherThing ) ) { // whatever } Tends to indicate a case where an extension might rightly choose to return false on purpose. -- Jim On 6/20/07, Daniel Cannon <cannon.danielc(a)gmail.com> wrote:

On 21/06/07, Jim Wilson <wilson.jim.r(a)gmail.com> wrote: In which case, one would return false. Rob Church

Thanks for chiming in everyone. Hopefully this new behavior will save some aggravating extension-conflict headaches, and it seems the consensus is that not-returning a value should always be considered a bug in the extension. Determining whether it was intended to return true or false or a String would have to be based on what the extension was trying to achieved, but in most cases it was probably just a forgotten "return true". Brion wrote: Since NULL is not an acceptable value, throwing a full-stop seems appropriate (to me). This certainly would have saved me some debugging time in the past :) Brion wrote: I agree, and I'd add that coaxing NULL values into true may also cause subtle breakages where one hooking method "expects" another hooking method (in another extension) to have killed the wfRunHooks() stack due to the original behavior. Granted this is an edge case, and most likely indicates a bug in one or both extensions. As a writer of multi-version compatible extensions, I appreciate steps taken to facilitate BC. -- Jim On 6/21/07, Brion Vibber <brion(a)wikimedia.org> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jim Wilson wrote: > >> Per r23133, any function that is called by a hook and does not return a > >> value will through a full stop error. > > > > Since not returning anything in PHP is equivalent (more or less) to > > returning null, is there any concern that the extension writer's intent > was > > to do so? Or is this simply a massive case of forgotten "return true" > > statements? > > > true - continue running hooks, and return 'true' from wfRunHooks() > false - cancel all remaining hooks, and return 'false' from wfRunHooks() > a string - display the string as an error message, and return 'false' > from wfRunHooks() > > NULL is not a valid return value, but it's not a string and it evaluates > to false when checked in boolean context. Since true is what is intended > 99% of the time, the NULL default return breaks things. > > > There's three ways to handle that: > 1) Ignore it -- what we did before ;) > 2) Toss a big error message so it's obvious it needs to be fixed -- what > I just added to try it out > 3) Change it to treat as if you returned true instead of false -- what > Tim suggests as the most convenient behavior > > > - -- brion vibber (brion @ wikimedia.org) > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > http://lists.wikimedia.org/mailman/listinfo/wikitech-l >