- 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(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l