[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: abstracted I/O, and my project.
- From: Mike Cuddy <mcuddy@...>
- Date: Tue, 10 Aug 1999 23:29:24 +0100
> 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
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"
> 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.