Re: A guide to building Lua modules

[Jeremy Ong <jeremycong@...>]

To offer a slightly dissenting opinion on one aspect of rule #3,
namely that while monkeypatching is a special tool for unique
circumstances, the developer need not go out of his way to prevent it
- I think I generally agree with that statement. When I write a module
for others, it's up to them if they want to abuse it or mess with it.
That's not really my concern since they implicitly know they are doing
something dangerous.

Generally, I think it's hard to predict when it will be useful to
monkeypatch, however rare it may be (a user-defined callback on every
invocation of a function for example). Better is to not try in my
opinion. Going out of your way to prohibit it on all exposed tables
certainly carries a certain code smell to me (fighting the language
semantics). Better perhaps is to isolate the code that should not be
tampered with and ensure that it is private.

On Mon, Apr 14, 2014 at 3:06 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 2014-04-14 11:03 GMT+02:00 Enrique Garcia Cota <kikito@gmail.com>:
>
>> I've written a series of articles about building Lua modules - it's here:
>>
>> http://kiki.to/blog/2014/03/30/a-guide-to-building-lua-modules/
>>
>> I would appreciate any feedback or comments on it.
>
> Rule #1: Do what Lua does
>    Agree 95%. The exception is table.insert, which violates the
>    rule "One thing, and one thing only". As a consequence,
>    table.insert(tbl,j,nil) and table.insert(tbl,j) do not mean the same.
>
>    Your article could add: supply concise but precise documentation.
>
> Rule #2: Always return a local table
>    Agree 95%. The exception is when all that the module does is
>    some monkeypatching :-)
>
> Rule #3: Allow monkeypatching
>    Agree 5%. No monkeypatching should be the default, and
>    it should be documented clearly when a module allows it.
>    Efficiency is not the only reason for caching system functions
>    locally, and designing module functions to be definable abstractly
>    is not all that easy.
>
> Rule #4: Make stateless modules
>    Agree 80%. The exceptions involve modules that are designed
>    to be used preloaded in interactive sessions.
>
> Rule #5: Beware of multiple files
>    Agree 95%. The exception is when the module requires
>    a module from the cpath.
>
> Rule #6: Break the rules
>     Agree 100%, when qualified by "but say why".
>