lua-language-server icon indicating copy to clipboard operation
lua-language-server copied to clipboard

Add support for overriding functions

Open evur opened this issue 1 year ago • 4 comments

The language server currently doesn't automatically infer types when overriding functions.

Example of the desired behavior:

---@class
FooClass = {
	---@return FooClass
	new = function()
		-- create an instance of FooClass
	end
	
	---@param foo number
	---@param bar string
	foo_callback = function(self, foo, bar) end
}

test = FooClass.new()

-- automatically infer types from FooClass:foo_callback
function test:foo_callback(foo, bar)
	-- foo is of type number
	-- bar is of type string
end

evur avatar Jun 09 '23 18:06 evur

There are also other issues requesting this or even reporting it as a bug: #1779 #1757 #1794

evur avatar Jun 09 '23 18:06 evur

Worth noting that the type inference here is half-functional, as described here: https://github.com/LuaLS/lua-language-server/discussions/1801 Hovering over the function will show the correct types, but they will not work within the function itself.

PinewoodPip avatar Jun 30 '23 21:06 PinewoodPip

#477

ImpleLee avatar Sep 13 '23 15:09 ImpleLee

Suggestion: Add this by default to every configuration file

{
    "Lua.diagnostics.disable": [
		"duplicate-set-field"
	]
}

Am I kidding? idk. I've been sitting on this for a couple of weeks as I accumulate many dozens of lines that say

---@diagnostic disable-next-line: duplicate-set-field

The more of those I have, the more wrong it feels. All of my work arounds feel worse. Sometimes the type of a field/member/whatever is a function, maybe with a specific signature. It's not sacred. It's a variable. Maybe just a value in a table.

I have 15 tabs open to pages discussing the issue. I've been reading them and browsing the LuaLS repos for hours now. The most frustrating of which is this one: https://github.com/LuaLS/lua-language-server/discussions/1801#discussioncomment-4579158

Maybe ---@override would be great.

I'm getting trauma flashbacks to luau's evolving type system with this issue. Getting the best of a flexible language like lua along with some of the comforts of a strongly typed language is hard. There were a lot of people looking at that and there was a lot of iteration. It's understandably very hard to get right.

There are languages and environments I would insist on having any callbacks run through a subscribe function. I think (100% opinion based) that a lot of places where lua is used and can benefit from LuaLS type inference and annotation, it also benefits from avoiding a temptation to dive into OOP and polymorphism and instead just embrace more functional styles, data oriented approaches, maybe interfaces with annotation.

I don't know that an ---@override annotation is going to get it right if someone gets around to taking a crack at it after all these years. I think as it's been the last few years, "duplicate set field" may be doing more harm than good and is better off disabled. Judging by the discourse, people are spending a lot of hours trying to work around it, changing the format of their code to try to appease the warnings, and I doubt anywhere near that amount of time has been saved by the warning working as intended.

mgmchenry avatar Apr 03 '24 03:04 mgmchenry