Module talk:Lua class

Globals

@Alexiscoutinho: Further to our discussion at Module talk:TableTools#Shouldn't isArray be more generic?, I had a quick look at this very nice module. There may be a couple of issues for you to contemplate. First, many modules require Module:No globals. If one of those modules tried to use something from here, it would be likely to crash because there are several globals in this module. Are they really needed, or should it return a table containing tables of functions + classes + instances? Second, are you aware that in function try_parser, calls to type() are calling Lua's function, not the _G.type modified function? Johnuniq (talk) 10:43, 11 July 2021 (UTC)

@Johnuniq: The globals probably aren't required, but are extremely recommended. I would prefer if such modules dropped their use of Module:No globals if they were to use classes. This module is meant to fundamentally change how other modules are structured and coded so it's only fitting for them to switch to globals. I wasn't aware of that type bug. I knew I shouldn't call it below that function override, but I completely forgot that the parser called it during the pre-submit check. I haven't extensively tested this module by the way. I was hoping to initially test it through examples and actual usage in other basic type modules (upcoming). Alexiscoutinho (talk) 05:24, 12 July 2021 (UTC)

The problem is that people have no way of detecting typos which generate unintended globals, so Module:No_globals is fairly common and may be becoming more so. I don't use it because I have a script which shows globals. I don't mind, I just thought I would point out the issue. Re "type", I would rename the variable to lua_type so there cannot be any confusion in the code or in the reader. Johnuniq (talk) 05:31, 12 July 2021 (UTC)

@Johnuniq: Well, I think the ideal solution would be to open more exceptions (besides "arg") in Module:No globals. Alexiscoutinho (talk) 05:51, 12 July 2021 (UTC)