 |
lua-l archive |
|
|
||
|
Am 17.04.2014 14:53 schröbte steve 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.
After further thinking I would exclude names that are used in previous Lua versions (the `setfenv` case).
(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.
Yes, but you usually don't call a function to get an error. The error is a symptom that the function couldn't complete its task. If you patch the function to succeed in more cases, that seems like a win-win, doesn't it?
* increasing the value range of parameters and/or return values of an existing function?Seems innocuous enough......
That's the `type` case, where you would return something other than the eight basic type names (which would mess up dispatching), but I have realized that those cases are a red hering anyway, because even if those patches are more or less compatible with legacy code, there could still be conflicts if you have two (or more) monkey-patchers. If you define a type of modification as acceptable, then it should be acceptable for everyone (and even adding a new function to an existing module can fail horribly if two monkey-patchers choose the same name but different semantics). So there is one additional mandatory condition for acceptable monkey-patches: There is _only one_ possible or generally agreed upon way to monkey-patch the given module/function!
And now it's getting pretty thin ...
But ... is not better to mark the new functions as being different, and give them new names/namespaces?
Probably :-)