Hello,
As I go forward thinking about integrating Mozart-Oz into Eclipse, I
realize that there may be three general options:
(1) Extending the CDT (have been posting to this mailing list about
this).
(2) Using the way the Mozart-Oz tools as they currently work as
specifications for an Eclipse implementation (with modifications to
incorporate the tools into Eclipse views, editors, etc.).
(3) A full integration of Mozart-Oz into Eclipse from scratch with the
tools looking entirely different to take full advantage of Eclipse
functionality.
In regard to (2), I have been thinking about what it would take to
translate graphical tools written using the Tk graphics engine into the Java
SWT widgets that are used by Eclipse. I am not fully familiar with Gump,
but perhaps, if I understand what it does correctly, linguistic abstractions
could be added to Oz such that Java classes (on a client) could be wrapped
(under the hood) by Oz classes (on a server), with communication in
between as a possible design alternative.
If the above scenario would turn out to be valid (in a sequential
program), how would the issue of the Java objects being stateful and
possibly launching threads of their own be handed by Oz, which uses threads
itself? As I understand it, handling state and threads is a difficult or
advanced topic. Does the Tk graphics engine as it stands take into account
threads in its operation and is Tcl/Tk considered stateful and can use
threads itself?
Sincerely,
Craig
P.S. Implementation (2) could be a step towards (3) if (1) is ruled out.
This is all conjecture until I actually write some code to test it, but I am
curious about the thread issue upfront.
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
