Compiler as dll

[Nick Sabalausky]

"Mike Parker" <aldacron at gmail.com> wrote in message 
news:glpfr2$b5o$1 at digitalmars.com...
> 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.
>

I disagree. Making all add-ons be interpreted scripts is one of the biggest 
reasons why Firefox (especially v2) is so absurdly slow (not that I'm a fan 
of IE, Opera or Safari). Also, the fact that the vast majority of scripting 
languages lack descent compile-time checking (such as static type checking 
or mandatory explicit declarations), or at least push it off as a secondary 
concern (modern ECMAScript), creates a situation where plugins have a 
tendancy to be unreliable.

But you're right that sandboxing is a potential issue. (Although even a 
scripting engine can still potentially contain exploits.)