Re: A guide to building Lua modules

[Jeremy Ong <jeremycong@...>]

In this thread there are a lot of comments about whether or not
monkeypatching is good or not. Having read it, it is clear that the
author is merely describing how to author lua modules adhering to the
principle of "least surprise." Not so much making a claim about how,
when, or why (or why not) monkey patching should occur. I really don't
think it needs to be clarified much more but I suppose it couldn't
hurt.

@enrique One very minor point of feedback I would suggest is changing
the title. "Building" implies compilation to me. May I humbly suggest
"A guide to authoring Lua modules" instead?

On Mon, Apr 14, 2014 at 11:32 AM, Enrique Garcia Cota <kikito@gmail.com> wrote:
>
> 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)