lua-language-server
lua-language-server copied to clipboard
LuaLS
Enhancements to properties
I'd like to declare @fields that might be:
- ready-only (i.e.
__index()exists, but__newindex()doesn't) - read-write
- dynamic (a new value is generated every time
__index()is called)
Just add keyword readonly
---@class A
---@field readonly x number
---@field private readonly y number
local A = {}
---@readonly
---@protected
A.z = 1
I would really like to document dynamic fields, like said above, field generated using the __index function. This would be really helpful when you have a class which has specific fields (so it's not just a table) but also an __index implementation. For example like this:
---@class Scene
---@dynamicField SceneObject? The object with the given name, if present
local scene = { }
--- Finds an object by name
function scene.find(name) end
--- FInds an object by id
function scene.findById(id) end
setmetatable(scene, { __index = function() end }) -- You know what I mean
-- Example usage
local player = scene.player
Currently this would cause a warning because player isn't a field of Scene.
You wouldn't need an option to set the name of the field with the @dynamicField (or @dynamic I guess), because that depends on the actual field requested. For the documentation, if you want to go all out you could add something like @name to be inserted into the documentation comment, which would then be replaced by the actual name of the field you access when you hover over it, but I guess that's not so important.
Just to document my own use case for dynamic fields, I'm worried about an user caching values:
local pos = obj.getPos()
-- much later...
pos.x --< no longer reflects `obj`'s state
Just to document my own use case for dynamic fields, I'm worried about an user caching values:
local pos = obj.getPos() -- much later... pos.x --< no longer reflects `obj`'s state
Is this supposed to be a comment on my post, or unrelated?
Is this supposed to be a comment on my post, or unrelated?
Unrelated. I just wanted to make sure that everybody understands that multiple use cases are on the table.
The request in this issue clashes with the request in issue #1298.
if we had a never type (the type with no values) then this one becomes a subset of that one - a readonly field is one whos write type is never, and writeonly one whos read type is never - and never would be a sensible default for the unspecified one if a field is only specified on one side!
