Re: A guide to building Lua modules

Hi,

Lua being a dynamic language doesn't mean that you should monkey-patch (or allow monkey-patching). Lua also is a language that allows you to prevent monkey-patching for certain modules, so it basically comes down to "Allow monkey-patching because I like monkey-patching" which by your own definition isn't a good reason.

It's not a matter of likeness. I don't like monkeypatching more than any other tool. I use it very sparingly. It can do some things that other tools can't - that's why it should be allowed. But it's also difficult to use correctly and dangerous, so it should definitively not be encouraged. I will try to make it more clear on the text.

In most cases I consider the use of standard library functions in my modules to be an implementation detail, so by caching them in locals I _enable_ you to monkey-patch to your heart's desire without fear of breaking the functions of my modules.

"Breaking the functions of my modules" is a language trap. It has a negative connotations that are not really there. Change it with a more positive verb, like "patch the functions of my modules" or "fix the functions of my modules", and the phrase takes a different meaning.

I don't think that users should mokeypatch the modules they require willy-nilly. That should be the last resort - the last step before manually editing the code of the module in question. It is dangerous, but that doesn't mean that it should be "inhibited" by the module.

Your comment about making the dependencies more explicit is very interesting. I will see if I can make a note about it somewhere in the article.

locals are faster than upvalues, so for tight loops it might make sense to cache the upvalues defined at the beginning of the module in locals ... :-p

I am not opposed to caching things up in local variables when the performance tests show that it makes a significant difference. What I contest is doing it by default.

If you move your modules from `./my-package` to `./lib/my-package`, you should change `package.path` and not your module references!

That's one way to do it, yes. But I wanted to see if I could find a way around that, and the other problem is still present (having to change lots of files). There's also the fact that I know of at least one system that doesn't respect package.path when loading modules (LÖVE).

And your `current_folder` trick is (slightly) broken. When you run `my-package/init.lua` via `require( "my-package" )` `...` will contain "my-package", not "my-package.init"

It's the folder containing init.lua that I'm interested in - I needed something that discarded "the last file name", if it existed. Can you show me a test exemplifying what you think it's broken?

You just use `local mod1 = require( (...)..".module1" )` to get to your submodules.

That strategy is interesting and creative. Thanks for showing it to me, I will include it on my article.

However it is of no use when you need to "require a module from a sibling module" (require mypackage.module1 from mypackage.module2). I still think current_folder covers those edge cases better.

Thanks,

Enrique (kikito / @otikik)