Mike Parker wrote:
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.
And I should qualify that I think the DLL/object file approach is the
way to go for compiler plugins.
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.
