In this small, toy example, you might be right; but on a large wiki, I believe the
data-driven approach (iterating through the namespace list) is far better for maintenance.
I run one wiki that has tremendous customization by namespace, and has quite a few custom
namespaces too. If it used your explicit "line by line" approach (separate
assignment statements for every setting), there would be hundreds of these
nearly-identical lines. And every time someone added a new namespace, they'd have to
remember to update the configuration by hand (copy and paste, copy and paste) with the
potential for introducing careless errors. In my opinion, that kind of redundancy is a
"textbook example" of a system heading toward unmaintainability.
The data-driven approach just keeps working even when you add new namespaces. It
represents a business rule in a compact form.
You're right that the code would break if MediaWiki changed the meaning of namespace
IDs. I'm less worried about that than introducing a bug by hand in several hundred
lines of identical assignment statements.
You are absolutely right that the admin would need to understand this kind of code to
maintain the wiki. I don't see anything wrong with requiring this kind of domain
knowledge from a wiki admin. And in real code (not my toy example, thrown together to
answer a qusetion), it would be fully commented, and probably embedded in a class in an
extension, also documented.
DanB
-----Original Message-----
Boris Steipe writes:
while this looks elegant on the surface, this is almost a textbook
example of inadvertent obfuscation. No-one who does not remember the
connection between talk namespaces and their ID will be able to
figure out _why_ this loop is being run. Moreover, the code will
break in case this connection is at some point lost.