RE: Extending Lua in C, was RE: External modules

["Brian Hook \(Pyrogon\)" <public@...>]

> We're already talking about modular cross platform extensions 
> for Lua client libraries so Lua is getting more flexible on 
> the outside. It would be nice if this were complimented by a 
> tuneable and extendable interior where you didn't have to 
> modify the code base for every application. 

I think there are obvious things that can be modularized, and other
things that would require a significant amount of work and/or ugliness.
The GC modifications don't sound trivial to modularize, for example.

But if it's a case of using a function pointer instead of calling a
function directly, then I'm all for modularization, with reasonable
fallbacks if none are provided.

The only complication from callbacks is that it sometimes makes the
library itself less robust due to user error (user mixes up the
callbacks, etc.) and it has to provide (ideally) more error checking to
verify that a callback is non-NULL.

In addition, you then have to deal with calling convention issues, which
means making sure you have a cross-platform mechanism for declaring
cdecl vs. stdcall vs. fastcall.  But this is easy enough to virtualize
into a macro.

> And, I think it 
> says something that people want to keep absorbing the 
> continuing work of Lua and not fork it. Keep up the good work.

Absolutely.  I find that with the better open source libraries that I
end up implicitly trusting a lot of the architectural decisions the
designers make, but that sometimes there are key implementation issues
that don't work as well for me because of my particular target
environment.

Brian