Class constructor and instantiation function definition

[xuhuanzy]

Possible grammar

---@class ConstructorParameters<T>
---@class RemoveSelf<T>

---@generic T
---@inject_class T constructor({nonColon=false, returnSelf=true, name=""__init""})
---@param name `T`
---@return T
local function class(name)

end


---@generic T
---@param name `T`
---@param ... RemoveSelf<ConstructorParameters<T>>
---@return T
local function new(name, ...)

end

while also removing runtime.classDefaultCall

[xuhuanzy]

@CppCXY @taminomara @clason @lewis6991
Public Opinion Solicitation

[taminomara]

I like the second option (new) more.

I feel like definition for constructor function should belong in a base class:

--- @class Base
--- @constructor(forceNonColon, forceReturnSelf) "__init"

Also, I see that some people already started using runtime.classDefaultCall, so we should probably deprecate it and warn users via some diagnostic.

---

In theory, we can postpone implementing this until we have more meta-programming utilities, and then do something like:

--- @class Base
--- @overload fun(...: std.RemoveSelf<std.Args<std.RawGet<self, "__init">>...>...): self

--- @generic T: Base
--- @param name `T`
--- @param ... std.Args<T>...
--- @return T
function new(name, ...) end

This approach is transparent, but it requires way more utilities (std.RemoveSelf, std.Args).

[xuhuanzy]

--- @Class Base
--- @overload fun(...: std.RemoveSelf<std.Args<std.RawGet<self, "__init">>...>...): self

The purpose of this proposal is to reduce the need for writing : Base to achieve implicit definitions.

Therefore, it is undesirable for every class to explicitly inherit from Base. At the same time, we do not allow subclasses to acquire the @overload from their parent class.

std.Args...

ConstructorParameters<T> This definition originates from TypeScript, and I believe the TypeScript definition is superior.

[taminomara]

The purpose of this proposal is to reduce the need for writing : Base to achieve implicit definitions.

If so, I feel that this should be configureable in .emmyrc.

I can imagine a situation where several libraries use different constructor names and class instantiation mechanisms. In such case, users should be able to turn implicit constructor inference off.

At the same time, we do not allow subclasses to acquire the @overload from their parent class.

I still think that we should. I mean, we inherit all other methods, why not @overload?

[xuhuanzy]

If so, I feel that this should be configureable in .emmyrc.

I can imagine a situation where several libraries use different constructor names and class instantiation mechanisms. In such case, users should be able to turn implicit constructor inference off.

This proposal aims to remove the configuration in .emmyrc and shift the implicit inheritance rights to the actual defining functions.

I still think that we should. I mean, we inherit all other methods, why not @overload?

The @overload attached to ---@class is equivalent to defining a constructor in LSP, and constructors in most languages cannot be inherited. We adhere to this rule.

[xuhuanzy]

remove ---@class ConstructorParametersNonColon<T>
ADD ---@class RemoveSelf<T>

[taminomara]

The @overload attached to ---@Class is equivalent to defining a constructor in LSP, and constructors in most languages cannot be inherited. We adhere to this rule.

Does it make sense for Lua, though? Is this desireable for most users? I've never seen class libraries that don't inherit constructors. Usually they resemble something like this:

Base = { __init = function(self) end }

function makeClass(base)
    return setmetatable({}, { __index=base or Base })
end

function new(cls, ...)
    local self = setmetatable({}, { __index=cls })
    self:__init(...)
    return self
end

--- @class Vec2
Vec2 = makeClass()

--- @param x number
--- @param y number
function Vec2:__init(x, y)
    self.x = x
    self.y = y
end

--- @class EuclidianVec2: Vec2
EuclidianVec2 = makeClass(Vec2)

--- @return number
function EuclidianVec2:length()
    return math.sqrt(self.x ^ 2 + self.y ^ 2)
end

In this example, Lua inherits constructors:

local v = new(EuclidianVec2, 3, 4)
print(v:length()) --> 5

So I'd expect EmmyLua to do so as well.

[lewis6991]

I'm struggling to understand the necessity of the proposals here.

The convention I use to construct classes is of the format:

--- @class A
local A = {}

--- @return A
local function new_a(arg1, arg2, arg3)
  return setmetatable({
      field1 = f(arg1),
      field2 = f(arg2,
      field3 = ...,
      field4 = 'init_val',
  }, { __index = A })
end

And right now there is no type checking on the field assignments in setmetable, but I guess that is a separate issue.

I see the example in the OP is about generic constructors for any class. So far I thought users would just do:

--- @generic T
--- @param name `T`
--- @return T
local function new(name, ...)
end

There is no standard way to define constructor arguments for a class, so I'm not sure can (or should) do anything here as these kinds of constructors are highly dynamic.

Perhaps there is a more concrete use case that can help me understand this more?

[xuhuanzy]

@lewis6991
Referencing https://github.com/xuhuanzy/rxlua/blob/master/luakit/class.lua, in the gaming industry, we often require a more comprehensive class definition, which in this case must be implemented through a control center.

This is also the approach taken by the author of luals, and the Lua solutions for Unity and UE are similar to this.

[xuhuanzy]

@taminomara The parameters required by a subclass constructor are not always consistent with those of the parent class, and the trouble brought by implicit inheritance will be even greater

[xuhuanzy]

Essentially, the proposal is to remove runtime.classDefaultCall

[xuhuanzy]

This proposal is indeed difficult to understand for people outside the gaming industry, but both cppcxy and I developed it from a gaming industry perspective.

[taminomara]

@taminomara The parameters required by a subclass constructor are not always consistent with those of the parent class, and the trouble brought by implicit inheritance will be even greater

Then users should override the constructor? I mean, what happens when you instantiate a class that has a base and doesn't override its constructor? Does it just... ignore the base constructor and leave class uninitialized? This is just a foot gun then, your classes can't have any non-public invariants and can't count on constructors being called. It's impossible to ensure any kind of safety in this scenario.

Bottom line is this. If a language doesn't inherit constructors, it will not let you initialize a class with non-trivially-constructible bases unless you explicitly provide a new constructor.