How would I create a Lua interface so the user can write his/her code in a startup() method and a runloop() method (1 Viewer)

[AI_Messiah]

So what I want to do is to have these two methods where some setup can be done with the startup method, but I want the method to be able to finish and have Lua still hold on to some of the stuff that was created within it and to be able to have a runloop method to be able to do the same. I also want the user to have access to methods and functions that I have already written myself. What I mean is that I do not care really about what types the user wants to use as long as he/she can interact with my implementation. It is mostly values supplied and values returned.

 

[GavinW]

Forgive me, but I find this very opaque. Finish what? To do the same as what? Please remember that us mortals are not telepathic. I use an operating system in which the window manager is the task-manager and user-applications have to co-operate with it if they want to use the graphical user interface. In other words, the user-code and system-code run as mutual coroutines. The usual approach in these circumstances is for the user-task to be defined as a table, with methods init and run. The first is called to register the user-task with the task-manager, and the second to call an endless loop of interactions of the form

while not quit do
    local response = call_task_manager (self)
    quit = handler[response] (self)
end -- while
self:closedown ( )

where call_task_manager passes execution to the task-manager (corresponds to coroutine.yield). The task-manager eventually returns a response code, which the user deals with using a table of handler functions. When a handler function returns a non-nil value the user-task closes down. The call to the run-method obviously has to be the last statement of the program. The user-task's behaviour once it is running is determined by the handler-functions.

Does this make any sense at all. I am replying blind, I am afraid.

 

[AI_Messiah]

Well I guess I could keep a record of variables and functions/methods declared outside of the startup() and runloop() routines and as separate scripts give them access to the variables and functions. I am quite new to this and I think I am going to take a course. Right now it would not make sense to start working on the implementation because I don't have everything worked out or at least that is what I think.

 

[dinsdale247]

It sounds like you are looking for a shared table. You would have three scripts. The main script would contain a table variable. The main script would then call the startup script and then the runloop script. There are a few ways you could work it. The sub scripts might have an init function or the functions expect a state variable (e.g. your shared table), or you could leave the shared table as a global and use do_file. Gavin presented a nice pattern for late binding of functions to keys.

local shared_table = {}

local startscript = require('startup')
startscript.startup(shared_table)

local runscript = require('runme')
runscript.runloop(shared_table)

 

[AI_Messiah]

This seems to be a really good answer, Thanks