On Tue, 27 Mar 2001, Christian Krone wrote:
> Hello,
>
> yesterday evening it finally happended: the ensemble.test
> of [IncrTcl] was processed by Jacl without any failure,
> and I had even added one test case...
Ohhh, cool.
> But before I will look for the next command to implement,
> I want to reorganize the layout of the sources. Since
> I don't know, what the best way would be, I seek for your
> help. Let me first explain my current solution, which is
> really a temporary hack.
>
> I extend the Interp class, to load on demand the EnsembleCmd
> if "itcl::ensemble" is needed. This class is defined inside
> the tcl.lang package and the sources are put into
> .../src/jacl/tcl/lang. The compiled classes will thus go
> into jacl.jar.
Yuk. We need to be able to support extensions in Jacl.
> In other words: IncrTcl is no loadable package at all.
> I think, beside the name EnsembleCmd all of the above should
> be changed...
>
> A nice package name could be "tcl.incr", so the sources would
> be put into .../src/jacl/tcl/incr. The jar file containing
> all the Incr classes should probably be called incr.jar.
> And the loadOnDemand() inside Interp should be removed again.
I don't know if we should even put the incr Jacl code
in the same tree as Jacl. Why not have another tree
with its own ./configure and so on? That is what
Bruce did with Swank (Tk via Swing).
> But how would the new classes be loaded into the Jacl interpreter?
> Currently I have no idea:-(
From the users point of view, it should be as easy as
"package require IncrTcl". Your implementation would
most likely extend src/tcljava/tcl/lang/Extension.java.
I think most of the tricky stuff related to creating
your own ./configure is already done. The hard part
might be getting "package require ..." to work
when the ... package is in a .jar like incrtcl.jar.
I think the best way to implement that is to use
the manifest file to list what Tcl packages are
available in a given .jar file and the java class
name.
Mo
|
