Enhancements to properties

[vinipsmaker]

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)

[sumneko]

I can support readonly first.

[vinipsmaker]

I can support readonly first.

What syntax do you have in mind?

[sumneko]

Just add keyword readonly

---@class A
---@field readonly x number
---@field private readonly y number
local A = {}

---@readonly
---@protected
A.z = 1

[Rc-Cookie]

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.

[vinipsmaker]

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

[Rc-Cookie]

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?

[vinipsmaker]

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.

[C3pa]

The request in this issue clashes with the request in issue #1298.

[justarandomgeek]

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!

[kriasb]

I can support readonly first.

Any update on this?