Closed emiltin closed 1 week ago
if a profile includes another profile (like bicycle profile using the foot profile) and needs to modify the setting table we might want to keep it as a global table, but fill in in an initialize function:
api_version = 2
profile = {}
function initialize()
profile.continue_straight_at_waypoint = true
profile.weight_precision = 2 -- could be bound to a c++ member if needed
}
This issue seems to be stale. It will be closed in 30 days if no further activity occurs.
the api version a profile uses is indicated with a global in the lua profile. the profile settings are also set as a global table:
there's a problem with this, since values in the settings table sometimes depend on the api, e.g. for reading enums or setting the weight precision.
you have to load the lua file to read the api version, which will run the code in the global scope, thus calling the api. but the api and the corresponding sol2 bindings should depend on the api version. i.e. we need a way to first read the api version, then setup the bindings, and finally construct the settings.
to solve this i suggest moving all code that potentially uses the api into functions which are called by the c++ side when needed. instead of constructing the profile table as a global, we should have an initialize() function:
first the file and the api version is read from c++. the bindings are then setup according to the api version, and then the initialize function is called for version 2 and above, for version 1 would have to rely on the old behaviour with settings in a global table.
the same class Sol2ScriptingEnvironment currently handles different api versions, by sprinkling case switches across the code. this can quickly get messy. i might be better to have a base class and a sub class for each api version.