Re: Monkey Patching is Bad, Unless Really Needed (was Re: A guide to building Lua modules)

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

On Thu, Apr 17, 2014 at 2:20 PM, Philipp Janda <siffiejoe@gmx.net> wrote:
> So maybe we should try to define what "acceptable" monkey-patches are (in
> case legacy code might be involved) ...

It would be useful, considering that patching is on the table....

> *   adding new functions/fields to existing modules?

By the principle of what you don't see, you don't use, that's fine.
(But see below)

> *   adding additional (optional) parameters to existing functions?
> *   adding additional return values?

This can get tricky. We all know that a little care is needed with
string.gsub because of the extra return value.  If it's an old friend,
then the number of parameters and return values is part of the known
contract and we relax a little. Unless this kind of patching is
happening...

> *   handling arguments that previously would've raised an error?

Likewise, whether a function returns "nil,err" or raises an error is
part of the function's interface.

> *   increasing the value range of parameters and/or return values of an
> existing function?

Seems innocuous enough......

But ... is not better to mark the new functions as being different,
and give them new names/namespaces?

For one's own private fun purposes, patching is like tweaking a
configuration of an editor: making the language fit your thinking
better.  But then there's the danger of a private language developing.
Say one develops a big app with a Lua scripting interface and it gets
users.  They see a function, and look it up in the official docs, get
puzzled and proceed to puzzle everyone on Stack Overflow.