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

["Brownsword, Andrew" <brownsword@...>]

The idea of compile-time macro based customizability is intriguing, and is something that would very much suit my needs as we don't really need the dynamic nature of the modifications.  Conceptually at least the Lua team could provide "normal" and a "vectorized" implementation, and end-users could start for either of those and add their own customizations.


-----Original Message-----
From: Brian Hook (Pyrogon) [mailto:public@pyrogon.com]
Sent: Monday, November 18, 2002 1:45 PM
To: Multiple recipients of list
Subject: RE: Extending Lua in C, was RE: External modules


> 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