Suggestions for improving our constructors?

[ipsquiggle]

Hello, we are using a class system which requires passing in the constructor as a lambda. This plays quite poorly with LuaLS as far as I can tell. I've made it work, sort of sometimes, but am wondering if anyone has suggestions to make this more succinct.

Here's what I've got:

---@class TestClass
---@overload fun(self: self, param: string): self   -- 2a
---@overload fun(            param: string): self   -- 2b
local TestClass = Class(function(self, param)       -- 1
	---@class TestClass          -- 3b
	self = self                  -- 3c

	self.field_constr = param    -- 3a
end)

function TestClass:Bar()
	self.field_meth = "a"        -- 4
end

local test_inst = TestClass("b")

Okay, kind of awkward. Let's talk about what I've got here.

1. You can see here our class factory taking the lambda for the constructor. The source of the problems.
2. Double overload! The first overload (2a) gets applied to the function on the next line (unexpectedly?) and gives us proper type information within the constructor. The second overload (2b) gets applied when instantiating the class TestClass("b")
3. HOWEVER: 3a creates a "fields can not be injected" warning, because it sees self as just a normal parameter. In order to fix this, I have to redeclare the class in this scope (3b) and then provide some variable to the declaration to attach to (3c). This is highly unfortunate.
4. Unexpectedly (?) fields injected in other methods don't have any complaints.

After doing this, the autocomplete on test_inst is .field_constr,.field_meth, and :Bar() as expected. If I leave out 3b/3c, then .field_constr is missing (because it was an illegal injection).

---

So my question is: Can anyone suggest any ways to clean up this mess? Ideally, 3a just works all the time, 3b and 3c are not necessary at all, and in a perfect world, 2a is not even necessary. We have tons of legacy code and so can not change the way our class system works, and are trying to find a compromise that gives us the best type information and the fewest warnings.

---

Edit: cleaned up unhelpful wordings.

[ipsquiggle]

In a perfect world, I feel like passing self: self in the overload should trigger the same behaviour as a method definition, in that it allows injection (opposed to passing t: TestClass would treat it as a normal parameter and prevent injection)...

[ipsquiggle]

Side note to this: What is the actual behaviour of the self type? It's undocumented and I discovered it by accident.

[tomlau10]

I also noticed this self type before.
I duno much about it, but AFAIK there are some issues with it: It doesn't follow inheritance type 🤔

There are issues reporting this:

• ---@return self #2002
• FR: Allow 'self' return type to allow return type changing with inheritance #1505

And the workaround to that inheritance issue: #3057 (comment)

[ipsquiggle]

Ah interesting good to know. Thank you for your insights as always! 🙏

[tomlau10]

While I don't have any good ideas atm (since you said refactoring is not a solution due to tons of legacy code 😇)
I would like to reply to some of your points:

4. Unexpectedly (?) fields injected in other methods don't have any complaints.

You may already knew it, that you can only "inject" fields to variables that have @class attached to.
That's how you "fix" the situation of point 3.
But for (4) this is actually as designed I believe

• the TestClass local variable has marked with @class TestClass in line 4
• then when declaring methods using function TestClass:Bar(), the hidden variable self will also be marked with @class TestClass under the hood
• so self.field_meth is auto "injected" into TestClass
• this is different from (1), because the server has no way to auto mark self as @class TestClass
  and you also already knew that a variable marked with just @type behaves differently from a variable marked with @class

[ipsquiggle]

That all makes sense, thank you for the clear explanation!

I really sympathize with the contributors on this project, lua is super weird and lets you always do weird things, creating reasonable default behavior must be such a challenge!

[tomlau10]

I suddenly have an idea that, maybe you can use the plugin feature to achieve your need 🤔
https://luals.github.io/wiki/plugins/

• a plugin is like a custom special script read by the server for your project
• one of its ability is OnSetText which can transform the text buffer of a file when viewed by the server
• so in the script you can use some string pattern matching and replacing, to transform the code in your ideal case become the "awkward" form which is needed by the server to make it work 🤔 🤔

Here's my try

• plugin.lua

function OnSetText(uri, text)
    -- print(uri, text)

    -- fix custom constructor
    local diffs = {}
    for start, overload, className, finish in text:gmatch '()(---@overload[^\n]+\n)local (%w+) = Class%(func[^\n]+\n()' do
        -- print(start, "|", overload, "|", className, "|", finish)
        diffs[#diffs+1] = {
            start = start,
            finish = start-1,
            text = overload:gsub("fun%(", "fun(self: self, "),
        }
        diffs[#diffs+1] = {
            start = finish,
            finish = finish-1,
            text = ("---@class %s\n---@diagnostic disable-next-line\nlocal self = {}\n"):format(className),
        }
    end
    return #diffs > 0 and diffs or nil
end

• what this plugin is doing
  • capture classname in (1) and the whole overload line (2b)
  • insert the captured overload line before (2b) but with self: self injected in it
  • finally add the ---@class %s\n---@diagnostic disable-next-line\nlocal self = {}\n after location (1)

PS: duno why need to use local self = self instead of just self = self, otherwise the field inject won't take effect during workspace init 😕
and the ---@diagnostic disable-next-line is used to silent the Redefined local `self` warning

demo

(diffed.lua is a debug file showing the transformed buffer, generated by the server when starting it with --develop, more details on official wiki page)

however...

I experienced some issues with this "plugin" system...

• the auto complete triggered when you type test_inst. doesn't contain field_constr ...
  only if you press esc and retrigger it, this field will show up
• and if the class definition is placed in one file, say TestClass.lua
  and you create an instance of this class in another file
  => the field_constr is not recognized until you open this TestClass.lua once ... 😇
• I have no idea if this is a bug related to the plugin system
  or if this is the designed behavior of OnSetText (which only process files that are opened ?!)

edited:

‼️ I seems found a workaround for field_constr is not recognized until open this TestClass.lua once ‼️

• somehow the trick of ---@class TestClass\nself = self\n will not work on workspace init
  (somethings off in the type infer system I believe 😕 )
  because even without using plugin, the strange behavior persists
• I then found out that I can use ---@class TestClass\nlocal self = self\n 😂
  This seems to work during workspace init (without opening TestClass.lua once)
• I have updated my demo script above 👀

edit2

I updated the string replace pattern again to "---@class %s\n---@diagnostic disable-next-line\nlocal self = {}\n"

• this will silent the Redefined local `self` warning
• also by using local self = {}, the setType inline hint won't show up for this virtual local self line