Re: Exposing C data via userdata and tables

[Wim Couwenberg <wcou@...>]

> 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),

No problem at all.  As long as the lifetime of your userdata (i.e. its 
__gc behaviour) is correct, go right ahead!  I'd prefer this over a 
C/C++ implementation any day.

> 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...)

My "style" in packaging C/C++ libs is to keep *as much* of the binding 
in Lua itself.  It is far easier to set-up and tweak a bunch of Lua 
scripts than their C/C++ alternatives and just as powerful.  I usually 
put the C/C++ part as a "private" (light) userdata member in a Lua 
object (i.e. a table).  Then you can use plain Lua tables, metatables, 
functions etc. to decorate your Lua object system.  Moreover, the (now 
considered private) userdata methods can be very low-level (just export 
some existing API calls more or less 1-on-1) and make them scripting 
friendly in the Lua object wrapper.

HTH,
Wim