-
Notifications
You must be signed in to change notification settings - Fork 57
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
Cannot define a readonly global with mutable fields #90
Comments
I don't think it is currently possible to lint for that, nor will I likely have time or interest in figuring it out. If you can figure out a clean way to implement it I'd consider a PR contributing a new config. |
If there are a fixed set of fields that you'd expect to be mutable, you can explicitly mark them out as being mutable on a global read-only like so: .luacheckrc
test.lua
(If the fields can be tables, you'll also want to add "other_fields = true") This seems to only work for globals/read_globals defined in a std, not if you define them directly in the config file. I don't know why, and this isn't clearly documented; I found this by playing around with the luacheckrc file a bit. ¯\ (ツ) /¯ |
Yes, there is a fixed set of fields that are mutable: all possible fields. |
That isn't what "fixed set" means. Is there a master list of all possible top level keys? |
It's basically access to something like the Unix environment - C strings indexed by C strings. |
There is also the opposite problem, how make the global mutable but all its field readonly?
and then I have some global string:
even objects with string fields: Then the string itself should be mutable but the function Note: This is just an example but pose the case I have 100 functions and 100 strings, then I have to manually specify 10000 cases to make the base object read-write but fields read-only? |
Why not something like this?
|
Reading the documentation I see no option to declare a global readonly (so that it cannot be replaced) but making all its fields mutable.
Understandably this is not a great interface but it's a fact of life that a runtime provides its data to lua code in this fashion.
The text was updated successfully, but these errors were encountered: