[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Exposing C data via userdata and tables
- From: Peter Colson <pcolson@...>
- Date: Tue, 22 Mar 2005 15:14:08 +1100
I've been reading the Programming in Lua book, in particular the Ch28
sections on user data, meta tables and OO access.
I think what I describe below is possible, but just want to confirm.
Basically it's whether tables of user data objects are feasible.
The problem to be solved is providing an extension library in C that
allows access to lists of spooled files in output queues. Ignoring the
output queue side of the implementation for the moment, the current
implementation simply exposes functions that can be called from Lua to
generate a single list of spooled files. It is then possible to cycle
through the list and open a spooled file based on attributes stored in
the list. There is no object-oriented access currently provided,
everything is accessed and invoked through the package table name
(splf.openlist, splf.getnextinfo, splf.open, etc.). The extensions are
also not thread-safe as the lists and currently opened spooled file are
simply static globals within the extension library.
It seems to me that the concept of "spooled file" is a candidate for
user data in that there are OS-specific structures/handles/current
position/etc. that represent a spooled file and it's state that cannot
be represented as Lua values but could be held within a user data
typedef struct SpooledFile
// Necessary spooled file detail fields, OS-specific structures, etc.
Exposing this via Ch28 techniques then allows for the following:
local SpooledFile = splf.new(SplfInfo, JobInfo)
local l = SpooledFile:getline()
while (l) do
l = SpooledFile:getline()
This is thread-safe as it is now the Lua VM instantiating and owning a
spooled file object, not the extension library managing a single
(current) spooled file.
Now with a list of spooled files I could either:
a). Create another user data object that internally manages a list of
SpooledFile C structures, or
b). Represent the spooled file list as a Lua table of SpooledFile user
This should then allow for:
local SpooledFileList = splf.newlist(...)
local SpooledFile = SpooledFileList:getfile() -- defaults to first file
SpooledFile = SpooledFileList:getfile(3) -- get third file in list
SpooledFile:open() -- etc.
The spooled file list object is also now thread-safe as it's
instantiated and managed from within the Lua VM.
So the basic questions are:
1). Whether there is any problem using user data objects in a table
like this (if there is then I guess I need the spooled file list user
data object of option a),
2). For option b), whether I have to instantiate and manage the Lua
table internally in the package library to allow the OO-style access
above (SpooledFileList:getfile, etc.) or whether I could use a basic
Lua table from within Lua and tack on the SpooledFileList methods to
that Lua-based table? (My feeling is I don't imagine I could do this in
a clean encapsulated way using just a Lua table from within Lua really,
it needs to be managed in the package...)