I would like to use D as a "scripting" language for my D app.
There seems to be no such thing.
Since we can include the D compiler in our distribution, it is
easy to enable "plugin" capabilities, but directly interfacing
with the source code seems like it would require a bit of
work(duplicating the code that one wants to include so it can be
linked in and "hot swapping").
e.g., Suppose I have a program like
struct X { ... }
void main()
{
runScript("X x;"}
}
for the script to have access to X, it must be included in the
script being compiled. That requires it having access to the
"program code". I'd have to remove all the stuff I do not want it
to have access to and that could be a real pain.
But surely we can use attributes, something like
@scriptable struct X { ... }
that is makes X exportable to an obj file that can then be
included in to the script. Everything, then, in my program, that
is marked as such can be accessed and the script becomes a simple
DLL. Dealing with hot swapping is then the only trouble. For
simple scripts, this shouldn't be a problem though.
Anyone see a way that this could be achieved rather easily? Say,
at compilation, a template gathers all the scriptable elements,
gets their source code(which would usually be classes, structs,
enums, functions, and some global variables, and emits the code
in a way that ends up in it's own object file(since we can't
write to files at compile time ;/)
Then in the scripting section of the app, It's just a matter of
compiling with the obj file to give the script access to some of
the program internals.
D needs an export("filename")... I'm ok with the security hole.
No need to bust my balls for it. A switch could be required to
enable it or a mail in rebate. No need to force me in to a box
that doesn't exist, is there? (could only export to the -J path
and maybe require a few other hoops to jump through if one is so
worried about security... maybe an optometric scanner?)
