lua-users home
lua-l archive

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


On Tue, Jan 12, 2016 at 2:58 AM, Nagaev Boris <bnagaev@gmail.com> wrote:
> On Tue, Jan 12, 2016 at 9:19 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>> 2016-01-11 23:42 GMT+02:00 Matthew Wild <mwild1@gmail.com>:
>>
>>>> OK. But what are the chances of this being added to stock Lua in the
>>>> next version?
>>>
>>> Based on the number of patches enthusiastically posted to this list,
>>> and the number that ever get in - I'd say the answer is "very low".
>>
>> Jonathan's suggestion is merely a change to a library, not
>> to core Lua. In such a case, there is an alternative route to
>> respectability: contribute a module to LuaRocks. Let's say that
>> the module 'jgstring' returns a function that monkey-patches
>> the string library, saving the original functions in string.orig.
>>
>> Once that is installed, it is a matter of
>>
>>    require"jgstring"()
>>
>
> I would prefer if that module returned new function string.match
> without changing any globals.

The catch here is that in order to create a module containing my new
functions (find, gmatch, and gsub in addition to match), I (assume)
would have to copy-and-paste all of the pattern matching code, roughly
500 lines of code, into my new module, just to change about 10 to 15
lines. That does not seem like a reasonable plan of attack.

The only reasonable way to do this, unless I'm missing something, is
for the change to be made in stock Lua, which is not asking that much
(given the simplicity of implementation and the lack of any backwards
compatibility issues).

The only alternative I can see is for me to maintain a lightly
modified fork of Lua on GitHub that makes my changes available,
possibly by defining a symbol like LUA_CUSTOM_BALANCE. I'm considering
doing this anyway, but at this stage, I'd really rather not be
maintaining a fork.