Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Properties/readonly fields #791

Open
Frityet opened this issue Aug 23, 2024 · 5 comments
Open

Properties/readonly fields #791

Frityet opened this issue Aug 23, 2024 · 5 comments
Labels
feature request New feature or request

Comments

@Frityet
Copy link

Frityet commented Aug 23, 2024

Some lua libraries have tables which have fields that can be read from, but not written to:

local tbl = setmetatable({ _data = { a = 4 } }, {
    __index = function(self, k) return self._data[k] end,
    __newindex = function(self, k)
        return error("Not allowed to set field "..k.." in table "..tostring(self))
    end
})

print(tbl.a) --ok
tbl.a = 4 --runtime error

Perhaps syntax such as

local record MyTable
   a<readonly>: integer
end

local tbl: MyTable = ...

print(tbl.a) --ok
tbl.a = 4 --compile time error

Could be introduced?

@Frityet
Copy link
Author

Frityet commented Aug 23, 2024

Furthermore, as an extension, maybe full properties could be introduced?

local record MyRecord
    x<get=get_x, set=set_x>: integer
end

function MyRecord:get_x(): integer
    return 42
end

function MyRecord:set_x(val: integer)
    print("setting x to "..val)
end

local tbl: MyRecord = ...

print(tbl.x) --42
tbl.x = 1 -- setting x to 1

which would turn into

local MyRecord = {}

function MyRecord:get_x()
    return 42
end

function MyRecord:set_x(val)
    print("setting x to "..val)
end

local tbl: MyRecord = ...

print(tbl:get_x())
tbl:set_x(1)

@hishamhm hishamhm added the feature request New feature or request label Aug 23, 2024
@lenscas
Copy link
Contributor

lenscas commented Sep 2, 2024

I am not a fan of full on properties. I don't like it when things that appear to be simply reading/writing to fields suddenly start to execute (potentially costly) functions.

Already have had plenty of times when things where much slower than expected because function calls where hiding in the code, pretending to be field accesses.

I do really like being able to say if a field is read-only though, and maybe set only as well.

@hishamhm
Copy link
Member

hishamhm commented Sep 3, 2024

Already have had plenty of times when things where much slower than expected because function calls where hiding in the code, pretending to be field accesses.

For better or worse, that is already a thing in Lua, because of metamethods.

I don't discount adding readonly fields in the future, though it can get either more complicated or less safe than what it seems initially, because of aliasing. One only needs to look at the constness rules from C and C++ to see that this can open quite a rabbit hole if one's not careful.

Having said that, I'm much less likely to add properties. The use-case suggested here sounds like a task for something like a compile-time metamethod (which is a more general concept than getter/setter properties). That would be more appealing to me, but I have no immediate plans to work on that either.

@hishamhm
Copy link
Member

The use-case suggested here sounds like a task for something like a compile-time metamethod (which is a more general concept than getter/setter properties). That would be more appealing to me, but I have no immediate plans to work on that either.

Update: Teal '24 has some progress in that direction, but the __index metamethod cannot be macro-expanded currently. Even if it could, it would not provide an easy way to implement getter/setter properties, so I don't have plans to focus on that right now.

@Frityet
Copy link
Author

Frityet commented Oct 13, 2024

awesome! thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants