You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Before 2019 or so, it was possible to get the _class, _propget, and _propset tables for a class and for a namespace. This allowed Lua scripts to reflect classes and instances, which I used for diagnostic and regression testing. (Also for a class browser to facility easier programming.) However, this access was closed down due (apparently) to security concerns. I now build in extra tables that allow for reflection when I register the classes, but this complicates my registration process when I want to add in a new C++ framework that has challenges (such as overloaded functions) that make it difficult or impossible to include in my standard registration process.
I can imagine that in many contexts (I am thinking games) the Lua environment needs to be relatively locked down. But I am working in a non-hostile environment where the user has to opt in to the Lua environment by installing the Lua plugin, and even then there is little motivation to cheat the system. So I am wondering if LuaBridge3 has an option to expose the class tables and if not, would you consider adding it?
Should be possible by accessing class metatable and using the internal keys luabridge use. Will try to provide some working snippets as soon as i'm back to the laptop.
I need to access them from Lua. It is a powerful tool for verifying the correctness of the LuaBridge implementation, as well as presenting the class framework to users as a learning aid.
We can design a specific help table for that. So registering a method could push an entry in the table with the description of the method and argument type as seen from c++ (but not name) registered in the class
Pre-2019, instead of hard-coded usersdata values the tables above had string keys, _class, _propget, _propset, and _static. (They may have been a _const key too, but if so I never used it.) I only need to be able to iterate them and get their names. I don't need to modify or call the values.
I am currently doing exactly what you suggested and adding helper tables as I register the classes. I use refl-cpp to reflect the C++ classes at compile time so that all of my registrations use the same code. The challenge with refl-cpp is that lack of useful support for overloaded methods. The current support would require me to know and hardcode the function signatures in the central routine where I'm processing them rather than in the lists where I list them, so right now I can't use refl-cpp for everything.
Repository owner locked and limited conversation to collaborators on Apr 1, 2023
Activity
kunitoki commentedon Apr 1, 2023
Should be possible by accessing class metatable and using the internal keys luabridge use. Will try to provide some working snippets as soon as i'm back to the laptop.
kunitoki commentedon Apr 1, 2023
Do you need to access them from lua or c++ ?
kunitoki commentedon Apr 1, 2023
this will print:
Will provide some facilities to extract this kind of information in a more straight forward way
rpatters1 commentedon Apr 1, 2023
I need to access them from Lua. It is a powerful tool for verifying the correctness of the LuaBridge implementation, as well as presenting the class framework to users as a learning aid.
kunitoki commentedon Apr 1, 2023
We can design a specific help table for that. So registering a method could push an entry in the table with the description of the method and argument type as seen from c++ (but not name) registered in the class
rpatters1 commentedon Apr 1, 2023
Pre-2019, instead of hard-coded usersdata values the tables above had string keys,
_class,_propget,_propset, and_static. (They may have been a_constkey too, but if so I never used it.) I only need to be able to iterate them and get their names. I don't need to modify or call the values.I am currently doing exactly what you suggested and adding helper tables as I register the classes. I use
refl-cppto reflect the C++ classes at compile time so that all of my registrations use the same code. The challenge withrefl-cppis that lack of useful support for overloaded methods. The current support would require me to know and hardcode the function signatures in the central routine where I'm processing them rather than in the lists where I list them, so right now I can't userefl-cppfor everything.