A guide to building Lua modules

[Inny]

This guy called "Kikito" wrote a nice blog series about authoring Lua modules and posted it on the Lua mailing list: http://kiki.to/blog/2014/03/30/a-guide- ... a-modules/

I think he makes a lot of great points. The Monkeypatching one is kind of controversial though.

I totally tried to make sure someone else didn't post this link already, no reason to make the guy blush twice

[kikito]

<blush>

It's still on alpha. The Lua mailing list guys have given me lots of feedback and I plan to improve it.

[davisdude]

That's a good link! I like it! Keep up your work on it (if you intend to do so, at least).
Just out of curiosity, how is Monkey-Patching controversial?

[kikito]

Just out of curiosity, how is Monkey-Patching controversial?

It's controversial on two levels.

First, there's people who view it as a bad practice - they think monkeypatching makes code unmaintainable (I think badly done monkeypatching makes code unmaintainable).

The other point is more subtle. It is related with the "extend" that a single monkeypatch should have. It could have "the biggest effect possible" (you change one function and everything changes), or modules could "resist" these changes (by creating local copies of everything for example). I think Lua is more on the first camp than on the second, so I think modules should not "resist".

I also think documenting which functions in your modules depend on each other and which ones are "fixed with locals" is important, independently of which side of the argument you are - I made a note to add that somewhere in rule #3. I also think that monkeypatching is difficult to use right, so it must be done with extreme care.

[Karai17]

That's a good link! I like it! Keep up your work on it (if you intend to do so, at least).
Just out of curiosity, how is Monkey-Patching controversial?

A lot of people aren't comfortably modifying external code to fit their niche purpose. Modifying how the system works can cause a lot of headaches if you don't keep track of it all. I personally try not to modify code already existing, but I don't mind extending code. For instance, in STI, I create a global string.split function that extends Lua's string API. I've been told this is heresy, but I like it.

[Roland_Yonaba]

For instance, in STI, I create a global string.split function that extends Lua's string API. I've been told this is heresy, but I like it.

Well, about that. Can I give my opinion on this ?
I also like extending things, but at least, you should warn your users, who were not expecting to find a new function to pop out when using your (amazing) library. Actually, most of the people who are writing libraries (and I am pretty sure you are already aware of that) would just try to avoid writing anything into the global namespace or not to tweak the standard library when writing their modules.

As far as I could see when peeking at the source of STI, string.split is only used in map.lua. I do not know if you are planning to reuse it somewhere else (or I might have missed some places in some other files where it is also used), but you do workaround that in two ways:
- Either you define this function as a local inside map.lua if it is only going to be used there.
- Or you can write it in some external utils.lua module, and then require this module anywhere in the code you might need this function.
That was my two cents. I am not saying you have to do this, but just that I think it will do better

[Karai17]

Well, if I was overwriting anything, I'd definitely think thrice about even doing it. However, since there IS no string.split (for whatever reason) I see no real concern. No one would be attempting to use it, let alone expect a different result. I used to have an extension of bit too, but I found a workaround.

I COULD make string.split into Map.splitString, but meh, I don't see a problem with how it is atm.

[Nixola]

What if I required two libraries which overwrite string.split, giving different versions of it? (Example, one returns a table and one returns every piece)

[Ref]

Thanks for supplying some guidelines for module construction.
Will definitely try to improve.

I'm confused by 'monkey patching'.
In Rule #3 you state:

However, sumult.mult(5,2) still returns 10, even after I have overriden sumult.sum.

Why would you expect that changing sumult.sum would cause sumult.mult to return something different?

I must admit that I really don't like the _call metamethod in single function modules and not localizing variables in modules because of pollution but that's just inexperienced me.

[Karai17]

What if I required two libraries which overwrite string.split, giving different versions of it? (Example, one returns a table and one returns every piece)

May god have mercy on your soul. In all seriousness though, this is a legitimate concern. If I come across this, I'll look into adjusting my lib.