luasandbox and missing functionalities

I was looking for implementing a class with setter / getter methods but I got stuck against the lack of rawget / rawset facilities in current codea version. I also found some discussion about modding codea changing the luasandbox file, and I wonder if it would be enough to enable the missing rawget/set. There’s some specific reason why not having them available? Considering also that, if I understood right, there’re some feature of codea that rely on them (like retina reso,ution support).

Also the ‘require’ keyword is not available. again there is a specific reason (something to do withso e restriction or limit) or is something we could hope to have in future versions?

Anyway, if features like that would be enabled by modding the sandbox file, what could we expect? Everithing working? bugs? Unexpected behaviours? Has someone tried before? and more over, there would be problem to release a game with codea runtime libs in that case?

Rawget/rawset, if I understand what they are correctly, are not there because they’re not necessary - lua objects/classes are really syntactic sugar, encapsulation and privacy and the like are not enforced - lua objects are simply tables.

As for require - no file I/O! So, nothing you would require. You can fake it by adding a new tab with the contents you would be requiring, and wrapping the whole thing in a table or class definition (I must admit, I’m fuzzy here - it would be nice to have a definitive way to emulate require() in practice)

In terms of using the runtime - I think very much that when you start going into the wild west of modifying the TLL-distributed code… Well, I can’t imagine it’s going to be very supportable, in terms of “what will happen if I do this?”. Try it! Worst case is it doesn’t work and you can post a more detailed question. I suspect many things simply won’t work, and it’d be up to you to fix them…

@shrike feel free to modify those files. I think you can potentially crash the app by enabling certain things.

I doubt very much that require will work at all — it needs to be configured to search for the correct patterns, and this will not work with the iOS app package folder structure unless we modify it — nor will it treat project names correctly (the only way I would be happy with require() is if we were able to modify it to allow for require(“Project:file”) syntax. Which might be possible.)

That said, rawget/rawset were only disabled because they can be used to enable the other functionality programatically. I think they are useful though and so I will enable them in the next release.

Hi @Simeon, thanks a lot for the reply. it would be great have the rawget/set available. @Bortels, the need is not just for encapsulation (even if that functionalties would allow to enforce it), but because that allow to implement nice and usefull constructs!

rawget/set allow bypassing the __index and __newindex metamethods when accessing table elements.

Hi @Simeon, so I suppose there’s no hope neither for the dofile() functionality? It would be very usefull in my opinion having something like that to directly use code automatically generated by tools like TexturePacker or others…

@shrike
You can use loadstring on a value saved to the data store (using saveLocalData for example) to get something like dofile functionality.

Hi @Dylan, not sure what you talk about could really help me. What i need is a way to load a file like

--fileToBeProcessed.lua

local myTableName =  { several infos }
return myTableName

i’m a noob of lua programming but for what I’ve understood the way should be to require(“fileToBeProcessed”) or to dofile(“fileToBeProcessed.lua”), with some difference on global namespace handling depending on the used functionality.

From what also @Simeon said before, i fear there’s no hope to have it working. Well, we can last without, even if it would be very usefull when handling file like this (that means libs, external modules or data decriptor generated by tools)