Hi, The Java interface allows only the construction of ECLiPSe data structures that conforms to the EXDR format. In particular, each occurrance of a variable within such a term is unique (so you can construct something like pred(V,V), which has two occurrance of the same variable V). It is meant to be a place holder, for the rpc to return some (ground) return information. So there is really no concept of ECLiPSe variables on the Java side, so the question of lifrtime does not really exists. This is part of the design of the interface. It is intended that each rpc should standalone, and have no state dependencies with another. If you need to return information during the execution of your rpc during its execution, this should be done via the queues. This might be somewhat different from what you seem to be expecting from the interface, base on the question you are asking. Note that this restriction to EXDR terms does not really limit the interface, but (by design) you may need to implement things a little differently. We have built quite complex applications using this interface, including the IDE for ECLiPSe (TkECLiPSe in Tcl/Tk, and Saros in Java). There is a reasonably complex example of how to program the Java interface in <ECLiPSe>/doc/examples/JavaInterface/EclipseMapColourer.java The paper "A High-Level Generic Interface to External Programming Languages for ECLiPSe", which you can download from ww.eclipse-clp.org/reports/index.html (it is in the `Prolog and Tools' section), discusses the concepts behind the interface in detail -- it is discussed mostly in terms of Tcl/Tk rather than Java, but it is basically the same interface. Cheers, Kish Wit Jakuczun wrote: > Hi, > what is a policy for lifetime of variables posted via > Java interface? Suppose I make a rpc call that > creates a variable (eg. I call predicate pred(V) ). > I store this variable as a CompoundTerm on a > Java side (using arg method) and use it in another > rpc calls. > > Is it correct approach? How variables stored > in CompoundTerm are protected from being > removed by gc? > > Best regards >Received on Tue Jun 03 2008 - 08:31:24 CEST
This archive was generated by hypermail 2.3.0 : Tue Jun 04 2024 - 18:13:21 CEST