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)

I can support readonly first.

I can support readonly first.

What syntax do you have in mind?

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.

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!

I can support readonly first.

Any update on this?

Navigation Menu

Repository navigation

Enhancements to properties #1901

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Enhancements to properties #1901

Description

Activity

sumneko commented on Feb 13, 2023

vinipsmaker commented on Feb 13, 2023

sumneko commented on Feb 13, 2023

Rc-Cookie commented on Feb 22, 2023

vinipsmaker commented on Feb 22, 2023

Rc-Cookie commented on Feb 22, 2023

vinipsmaker commented on Feb 24, 2023

C3pa commented on Mar 27, 2023

justarandomgeek commented on Sep 24, 2024

kriasb commented on Sep 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions