Stick to calling a class's public methods, rather than accessing its $mFoobar members, whenever possible
Meh. Getters and setters are clutter - just access what you want and be done with it. Keywords like 'private' and 'const' just end up making extension development more difficult.
Don't depend on implementation details of MW's methods, just the public interfaces
Well yeah, in an ideal world, yes. Unfortunately, it's sometimes necessary to clone swaths of the codebase to make a small functional change hidden where a wgHook doesn't reach. Use your judgement.
Call methods on the extension's $parser parameter, rather than $wgParser, when possible
Correct. In most cases the passed in $parser is what you want, but there /are/ instances where you'd want to create your own Parser instance and use it to perform a parse. For example if you want some wikitext parsed using pristine MW parsing rules, you'd create your own Parser instance rather than use the passed in one, which likely already has tags and parser functions attached to it. However, this is an edge case - for nearly all cases it's best to use the passed in $parser param.
Avoid modifying MediaWiki core code
Avoid modifying MediaWiki core code LIKE THE PLAGUE (there, fixed that for you). If you find you can't do what you need to given existing hooks, either ask on a list like this one, or insert a new wfRunHooks() call and hook into it - then ask someone in the group to commit it for you.
-- Jim R. Wilson (jimbojw)
On Thu, May 1, 2008 at 11:03 AM, Daniel Barrett danb@vistaprint.com wrote:
I agree, that's how I dreamed up the list of practices. At the same time, MW does expose classes' $mFoobar members publicly, e.g., Parser->$mOutput.
DanB
-----Original Message----- These are just proper OO practice, not specific to MW. Good coding practice is good coding practice. :)
Mike
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l