Compiler as dll

[Mike Parker]

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.