Re: A guide to building Lua modules

Hi,

The author of a module is not in the position to decide whether it's a good idea or not for me to patch their code in my circumstances.

I could not said it better.

As an example from personal experience, we found a bug in a module used to parse and specifically subtract datetimes [...]

Yes, your example is one of the things I had in mind.

o A key point that seems to be missing from #5 is that not everybody loads modules from the filesystem. In our environment, we have two searchers, the package.preload searcher, and our own custom searcher that searches an SQLite3 database (our application deployment format). If your multi-file module won't work if I concatenate all the separate files together, then it's of no use to me. I think this can be achieved roughly as follows:

If I understand you correctly, you are basically describing a system where `require` doesn't work. I understand where you are coming from, but also be aware that there's a blurry line there - if you take enough features from Lua, is it still the same language?

If I where in your situation, I would have monkeypatched (heh) require to do something like this instead:

local oldrequire = require

require = function(path)

local source = pcall(oldrequire, path)

if not source then

source = load_module_from_sql(path)

package.loaded[path] = source

end

return source

end

You would have to structure your database a bit differently (one register per module instead of one register per package) but you would have all the multi-file modules available, without having to modify any source code.

Regards,

Enrique (kikito / @otikik)