A guide to building Lua modules

[Inny]

Re: monkeypatching

I'm a follower of the belief that you be conservative in what you do and liberal in what you accept, also known as the robustness principle. Module code exists only in service to its user and is just some benign text file until that time. If the user wants to monkeypatch it, so be it. HOWEVER, Users probably shouldn't be monkeypatching, it's a crummy practice and makes reasoning about programs difficult. But as this is a guide to modules and not the global state of the Lua interpreter, the advice that modules be simple and handle being monkeypatched well is good.

I'd go a step further and say that modules should give its users a path of lesser resistance by being designed to be extendable. That's a little rough because the of no-self rule (a good one also), but you see this a lot in the javascript world where libraries either expose a fn member where it can be extended, or the library is designed so that the 'this' context has meaning and can be extended via object.create. As it applies to Lua, that means that the first parameter of each function is the primary target of operation. Yeah, I'm just getting around the no-self rule, but it makes perfect sense when you look at the do-what-lua-does rule and all of the string library works on a string as their first parameter.