lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On 16 April 2014 14:34, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 2014-04-16 19:15 GMT+02:00 Hisham <h@hisham.hm>:
>
>> Monkey Patching is Never Really Needed.
>
> Does strict.lua count as monkey-patching? I mean, really,
> what can be more fundamental than monkeying around
> with the way a language stores its global variables?

I guess it is, but I admit I was thinking in the narrower sense of
modules that go and peek into other modules replacing their functions.

Anyway, indiscriminate use of strict has its share of
monkey-patch-related problems. I've had problems in the past with
modules that do their own version of strict causing issues with other
modules. (I _think_ it was one version of stdlib loading std.strict by
default and then some test scripts from another module that uses
stdlib failing when using that version.)

On 16 April 2014 14:55, Philipp Janda <siffiejoe@gmx.net> wrote:
>> There are always better solutions; the mechanisms that allow monkey
>> patching are there for low-level metaprogramming, not for regular
>> module/application development.
>
> I agree in general, yet we both have contributed to a publicly available
> module[1] that does _nothing but_ monkey-patching ...

Well, yeah, but one could argue that this is almost the kind of
low-level plumbing I was referring to. Steve made us a good defense by
arguing that it has a disciplined interface. It's more like a porting
tool to run (restrained) Lua 5.2 code in a Lua 5.1 VM environment (at
least that's how I used it). In that sense, I think strict.lua should
also be used as a tool for testing rather than for integrating with
other reusable modules.

-- Hisham