What would be the best way to deal with inject-field warning in this case? (example inside)

[tomlau10]

Given the following code snippet:

---@class Pc
local Pc = {}
Pc.__index = Pc

local function initDbData(self, dbData)
    self.aa = dbData.aa -- inject-field warning here, I want to ALLOW it and let LuaLs merge this field to `Pc` class
    self.bb = dbData.bb -- inject-field warning here, I want to ALLOW it and let LuaLs merge this field to `Pc` class
end

function Pc.new(dbData)
    ---@class Pc
    local self = setmetatable({}, Pc)
    self.a = 1
    self.b = 2
    initDbData(self, dbData)
    return self
end

• Inside Pc.new() I can simply add ---@class Pc to annotate self such that LuaLS will know I want to merge the injected fields into class Pc
• But inside the initDbData local function, there is no way to annotate the self variable 😕
  As far as I know the ---@class is used to annotate the LHS variable in a statement? And none of the statements' lhs is the self variable in this case.

---

I can think of 3 ways, but all of them seems to have pros and cons

method 1

• Add a self = self dummy statement

local function initDbData(self, dbData)
    ---@class Pc
    self = self
    self.aa = dbData.aa -- now will be no inject-field warning
    self.bb = dbData.bb -- now will be no inject-field warning
end

But this looks very silly... as it is not pure annotation statement. And in the worst case some day another person may think that this is a useless statement and want to remove it 😅

method 1.1

• Almost like method 1, but use another function param name to make the assignment meaningful

local function initDbData(pcObject, dbData)
    ---@class Pc
    local self = pcObject
    self.aa = dbData.aa -- no inject-field warning as well
    self.bb = dbData.bb -- no inject-field warning as well
end

• Less silly, but still...

method 2

• Add the fields using ---@field manually

---@class Pc
---@field aa any
---@field bb any

• But then each time if initDbData() is updated with new fields, one have to update the ---@field as well.
• And I have to specify the type here, so cannot use auto type inferring
• Main downside is not automatic so it is not good either ☹️

method 3

• Use object method syntax

function Pc:_initDbData(dbData)
    self.aa = dbData.aa -- no inject-field warning now
    self.bb = dbData.bb -- no inject-field warning now
end

function Pc.new(dbData)
    ...
    self:_initDbData(dbData)
    return self
end

• This seems good as it does not require any extra annotation, and I can even use "doc.packageName": ["_[a-zA-Z]*"] to mark t._field as package/private fields to guard for invisible access.
• But then this requires a change of syntax in codebase and also I don't want to expose this function in the class namespace 🤔

[MillhioreBT]

I think you want to do something like this right?

---@class (exact) Pc
---@field __index table
---@field new fun(dbData: table):Pc
local Pc = {}
Pc.__index = Pc

---@param self Pc
---@param dbData table
local function initDbData(self, dbData)
    self.aa = dbData.aa -- inject-field warning
    self.bb = dbData.bb -- inject-field warning
end

function Pc.new(dbData)
    ---@type Pc
    local self = setmetatable({}, Pc)
    self.a = 1
    self.b = 2
    initDbData(self, dbData)
    return self
end

[tomlau10]

not really. I want to allow the field injection in both Pc.new and initDbData
i.e. LuaLs auto infers that class Pc has fields:

• a, b which are defined in Pc.new
• and aa bb which are defined in initDbData()
• without I explicitly specify these fields using ---@field

maybe my initial snippet is a bit misleading about the sentence inject-field warning, because I actually want to allow it. 😂
I just modified my snippet above to make it more clear 👀

[MillhioreBT]

I can't think of any other ideas, but I would maybe use: ---@field [string] any or ---@class Pc: { [string]: any }, however I don't think it meets what you really need.

[MillhioreBT]

I would also like to know if there is a way to create an annotation that automatically deduces the type of each field dynamically...
but for now I'm afraid we have to settle for the any type xd

[tomlau10]

If you specify every field as any, I think this will make things worse. 🤔

• Because when you don't specify a field type, LuaLS will try its best to deduce the type.
• But if you explicitly specify the field as any, then LuaLS will stop inferring the type and just treat the field as any.

---

Take the following example:

---@class Pc
---@field aa any
local Pc = {}
Pc.a = 1
Pc.aa = 1

When you look into the hover preview of Pc, you will see that

• a is of type integer => this is auto inferred
• but aa is of type any => as I explicitly specify it as any
  this is worse than no annotation as without it, LuaLS can infer this field as integer type ‼️

---

So in order to have automatic type deduction, I think the best way is to write as little ---@field annotation as possible

[CppCXY]

使用继承, 让Pc继承基类

[tomlau10]

不是太明白，繼承哪個基類? dbData嗎?

• 實際上 dbData object 的字段名，跟要 set 到 pc 上的，並非一一對應 😕
  就是不能說直接做 ---@class Pc: PcDbData
• 並且如果有1個 PcDbData base class
  不就需要手動對 PcDbData 加 ---@field 了?
  這個有點像我最初提到的 method 2 所引伸出的問題

---

我是想做到一了百了，自動 infer 出新字段
而不需要每次加新字段，就得手動加1個 ---@field

暫時來說可能是用 method 3 🤔