grauzone wrote:
When it's a commercial program, the DLL plugin approach probably
wouldn't work anyway: in order to enable others to compile plugins, you
would need to expose your internal "headers" (D modules). Note that
This is exactly what id software did with their Quake games. They
provided an SDK, which included the headers and source files required to
make mods. It was possible to use plain C to make DLLs or the QuakeC
language they developed. This was before scripting languages became big
in the game industry.
Personally, I would prefer a scripting language like Lua or Python over
DLLs/object files for a plugin framework, no matter the application
domain. The biggest reason is that it's easier to sandbox a script
engine. But both approaches have their place.
unlike in languages like C/C++, this would cause internal modules to be
exposed too, even if they are not strictly needed. What would you do to
avoid this? Maintain a separate set of import modules?
I think a purely extern(C) based interface would be better in these cases.
In fact, if you rely on the D ABI for dynamic linking, you'll probably
have the same trouble as with C++ dynamic linking. For example, BeOS had
to go through this to make sure their C++ based API maintains ABI
compatibility:
http://homepage.corbina.net/~maloff/holy-wars/fbc.html
I'm not sure if the D ABI improves the situation. At any rate, it
doesn't sound like a good idea.
