Re: Hooks for I/O, memory, etc?

[Terence Martin <tmartin@...>]

I think I'd have to agree. Even though it's simple to modify the core
to do things, I know a few people, myself included, have been sort of
leary of upgrading to a new version, simply because you have to remake
all those changes again. It would be a lot cooler if all you had to do
would be recompile your own sources and relink with the new version's
library and be most of the way (if not all the way, since the lua
authors take such pains to ensure compatability) towards being fully
upgraded to the new version.

There is also the situation where you want to use lua, but you don't
want to include the source in your own project. Like, you want
instructions that say "have lua 4.0 installed, as this code links with
liblua.a". That all falls apart if you need to, say, redirect internal
functions to a graphical console or something. You can't do that
because the person needs a modified version. I'm not sure how horrific
that actually is to most people, but I've run into that one myself.
Not to mention people that want to have lua .so or .dll files laying
around for multiple applications.

It would be cool if there was a function like lua_setcallbacks or
something like that. Which, by default, would all set to be exactly
what they are right now. So for most people, who don't really care,
nothing at all would change. But for the few that need that sort of
customization, they would just have to add a line before lua_open and
everything would be cool.

==============

On Mon, 10 Jun 2002 14:13:33 -0700
Pyrogon Public <public@pyrogon.com> wrote:

> > The drawback is that everyone using Lua would have to start 
> > it with something like
> > 
> >   lua_open(&realloc);
> 
> Compared to using the language as a whole, this seems like a trivial
> matter.  Startup and initialization -- especially if it's optional
> -- is easy to document, debug and understand.  Patching the core Lua
> code isn't =)
> 
> Brian
>