|Scripting language interfaces firstname.lastname@example.org (Steve Atkins) (1998-03-24)|
|Re: Scripting language interfaces email@example.com (1998-03-30)|
|Re: Scripting language interfaces firstname.lastname@example.org (1998-03-30)|
|Re: Scripting language interfaces email@example.com (Roland Kaufmann) (1998-04-03)|
|Re: Scripting language interfaces firstname.lastname@example.org (Martin Bertolino) (1998-04-03)|
|From:||Roland Kaufmann <email@example.com>|
|Date:||3 Apr 1998 17:10:27 -0500|
Steve Atkins wrote:
> Some people like scheme, some prefer tcl, others visual basic, and yet
my background is from object-oriented through imperative languages,
and not functional.
> It would be nice if the enduser could take its favourite scripting
> language plugin, add it to its new application and have everything
> work. It would save the 'which scripting language do we use?'
> decisions for application developers.
Support the idea. Perhaps even better would be if a common language
front-end could script multiple apps. This has been to some extent the
approach pursued by - dare I mention it - Microsoft with their
IDispatch interface in COM.
I've been into this problem myself. Implementation is to be done using
Java, so I have considered taking the quick route of having the
application supply a root object to the script-engine/compiled version
(from now: script). The script then uses Java reflection to get the
methods this object exposes. If a java.lang.Object is returned then
this in turn may be queried. Analogous, a Win32 implementation could
use IDispatch. Unices may go for an IIOP solution, but that may end up
being a major programming project in it's own.
Return to the
Search the comp.compilers archives again.