Re: Extending the io library

[David Manura <dm.lua@...>]

David Burgess writes:
> However, I have copied and modified the iolib.c code for so many io
> variants that I have lost count.  A universal solution in 5.2 would
> be nice.

I agree with the others that the Lua I/O library is insufficiently abstracted. 
It assumes that

  (1) A Lua file handle is internally implemented as a C file handle.
      This is not the case, for example, if I/O is via a window in
      a GUI application.  I've needed to patch hooks into the I/O library.

  (2) A Lua file handle is created in Lua, or it is one of
      the standard file handles (std*) when Lua is initialized
      (e.g. one can redirect the standard file handles prior to
      initializing Lua).

There are also a few base functions, independent of the I/O library, that
operate on standard file handles.  For example, loadfile when passed no
arguments loads from C's stdin, which is *not* necessarily io.stdin.
(BTW, does anyone even use the no-argument form of "loadfile()" in
practice?)  There are also print and debug.debug.

> 2. Write a wrapper class which mimics io objects, and use that. That's
> a real pain, as I'm basically reimplementing the io library for a
> couple of minor convenience features.

That sounds plausible, though it does assume the client doesn't use
io.type and friends, unless you reimplement them.  This is related to
Lua file handles not being virtualizable[1]--e.g. to implement
something like a C++ stringstream in Lua.

I also think the io.stdout v.s. io.output() v.s. whatever-print-writes-to
distinction might not be helpful.

[1] http://lua-users.org/wiki/LuaVirtualization