Re: abstracted I/O, and my project.

[Mike Cuddy <mcuddy@...>]

>    Yep, and for a similar purpose.  At first it seemed like it would be a
> Big Deal, but it turned out to be easy.  Especially if you don't need to
> support "real" Lua code.  (in other words, if you are free to take some
> liberty in your redefinitions of functions because of your special use of
> Lua)

I'm a big fan of "extensible I/O" (See my page on the zpp library
on my web site Http://www.fensende.com/zpp -- a C++ iostream interface to 
 .ZIP files ;-)  I must admit that I was kind of disappointed to see 
LUA'a I/O interface being so closely tied to FILE*'s.

>    Basically, you'll need to override print(), _ALERT() and probably
> write() on the output side, and read() on the input side.  print() and
> _ALERT() are easy to redefine in the host language.  And you'll get
> _ERRORMESSAGE() for free when you redefine _ALERT(), open up the i/o lib
> and you also get nicer debug messages for free.

I'll want to override those anyways for my game environment -- in fact,
I'll probably take them out of the LUA environment altogether for "security"
reasons.

>    Please share if you make any interesting discoveries - I'm definately
> interested in this topic.  :)

I did have a brief thought about rewriting the whole I/O subsystem to 
be "extensible", but I think I'll wait til' I have some more LUA under
my belt before tackling that task -- I would want the implementation to
be in the "spirit" of LUA, and until I've programmed a bit more in the
lanaguage, I wouldn't want to break "canon" ;-)

--
Mike Cuddy (mcuddy@FensEnde.com, MC312), Programmer, Daddy, Human.
Fen's Ende Software, Redwood City, CA, USA, Earth, Sol System, Milky Way.
I remember asking why ... Let it rain, and protect us from this Cruel Sun.

       Join CAUCE: The Coalition Against Unsolicited Commercial E-mail.  
                          <http://www.cauce.org/>