update

[xuhuanzy]

No description provided.

[lewis6991]

Is this really a good idea? Seems like all locations should be returned. Perhaps you can sort the results instead?

[xuhuanzy]

Is this really a good idea? Seems like all locations should be returned. Perhaps you can sort the results instead?

So I sorted the Find All Implementations to place the actual definitions as far forward as possible.

The compromise is that if there is a matching ---@field func fun(), then return that item along with the actual definition, discarding any other functions defined with @field.

[xuhuanzy]

Alternatively, we can enable this behavior when the number of declarations exceeds a specified threshold.

This behavior is enabled because, in practice, some functions may have a large number of declarations with the same name. A typical example is event. When dealing with hundreds of event overloads, the jump behavior should ideally take us directly to the most matching declaration rather than returning all options for selection, which would be highly inefficient and often meaningless.

[lewis6991]

In the example:

                ---@class T 
                 ---@field func fun(a:Goto1) # 1 
                 ---@field func fun(a:Goto2) # 2 
                 ---@field func fun(a:Goto3) # 3 
                 local T = {} 
  
                 function T:func(a) 
                 end 
  
                 ---@type T 
                 local t 
  
                 t.func(Goto1) 
                 t.fu<??>nc(Goto2) 
                 t.func(Goto3)

I would expect the locations returned would be the function definition and the matching @field. Removing #1 and #3 makes sense.

However if the argument type isn't known (e.g. is any), then everything should be returned

[xuhuanzy]

I would expect the locations returned would be the function definition and the matching @field. Removing #1 and #3 makes sense.

However if the argument type isn't known (e.g. is any), then everything should be returned

The current behavior of jumping to definition is similar, but it's important to note that if the actual definition is inherited from a parent class, it will not appear here.

Regarding definitions inherited from parent classes, I've observed that luals does not return them when searching for all implementations either. Perhaps we should return the actual definition from the parent class?

[lewis6991]

When defining classes, so far I mostly inherit from abstract classes, and not from any that implements definitions. What is the most standard way to do that in Lua?

I assume the subclass definition would need to explicitly call the parent class? If so then it's probably ok to not go to the parent definition. I'm not sure though.

[xuhuanzy]

@lewis6991
In Neovim, how are classes initialized in terms of format? Regarding the __call hint, cppcxy's opinion is that if it's local a = Class(), then prompt local a = new Class(), and if it's not Class(), then

[lewis6991]

Usually something like:

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

function Class:method()
end


function Class.new(arg1, arg2)
  return setmetatable({
    arg1 = arg1,
    arg2 = arg2,
  }, Class)
end

We don't have any formats for classes that inherit other classes because I don't know how to do it.

[xuhuanzy]

We don't have any formats for classes that inherit other classes because I don't know how to do it.

Generally speaking, it is achieved through several specific functions to centralize definition and instantiation.

Then this feature is not useful to you; currently, it only provides hints when ---@overload is present.