"Mike Parker" <aldac...@gmail.com> wrote in message news:glpfr2$b5...@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.)