Re: A guide to building Lua modules

[steve donovan <steve.j.donovan@...>]

On Mon, Apr 14, 2014 at 12:06 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 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.

Having actually now read the article, I can see the point - but I
wouldn't have made such a fuss - rule #3 is very minor in comparison.

The idea here is that it is rude to prevent people from patching all
your functions.  But there's a reason in OOP where methods are 'final'
- it's called the fragile base class problem.

Your first priority as a module developer is to give something solid,
reliable and deterministic.  This goal can be compromised by
monkey-patching.

I think the need to patch mistakes is there, sure, but to modify a
loaded module is modifying a global resource, which may be loaded
elsewhere from other modules.