Hi, Before I answer some of your comments, I would like to give some background on Gecode/J. Gecode/J is a very close mapping of the Gecode system into Java; it is not a pure modelling layer like some other Gecode interfaces (for example Gecode/R, http://gecoder.rubyforge.org/, by Andreas Launila). We made a deliberate decision to try and keep the concepts in Gecode and Gecode/J very close. A benefit of this close mapping is that it is possible to write simple propagators and branchings in Java directly. A drawback is that using Gecode/J incurs quite some overhead compared to plain Gecode.
There are several reasons we did the Java interface to Gecode. First of all, we needed it for teaching. One of the most important tools when teaching constraint programming is the graphical search engine Gist. In the beginning (back in 2005), we did not want to venture into making a platform-independent GUI in C++, so Java was a better choice. Since the re-licensing of Qt, Guido Tack has rewritten Gist in C++ using Qt, which gives us a nice and efficient GUI in C++ without the need to go via Java. Secondly, one of the claims of Gecode is that it is easily interfacable. We had to investigate this ourselves before making that claim. Our current use of Gecode/J is purely in a teaching context. As such, the basic introduction to the concepts of constraint programming is given in class, while the on-line documentation is used as a reference. We are, however, aware that the lack of entry-level documentation for Gecode can be a problem, and are looking to improve it (see http://article.gmane.org/gmane.comp.lib.gecode.user/1693). Please note that this will be for Gecode, not for Gecode/J. On Sun, Sep 14, 2008 at 6:27 PM, andrew cooke <[EMAIL PROTECTED]> wrote: > First, doxygen is cool, but Javadoc is the standard. The first thing I > (or any other engineer) does when assessing a package is look at the > JavaDocs. Please see the documentation pages for Gecode/J (http://www.gecode.org/gecodej/documentation.html). If you want to generate it yourself, just use make javadoc. > - Static import functions scare the cattle. Sure, you want FP in Java and > using static imports are like functions (woot). But Java isn't FP and > you're going to confuse old folks (you threw me). Especially when the > majority of the calls (I'm talking about calling Gecode.* methods from > within a Space) take a first argument of "this" (have you made a wrong > term somewhere and ended up in Python land?!). Why aren't these methods > in some subclass of Space? The constraint methods are not in a superclass of Space since they do not belong there -- a Space does not know anything of the various constraints that can be posted in it, and should not either (the principle of low coupling in pattern-speak). An important point in Gecode is to not differentiate between what we as Gecode developers can do, and what a user can do. If the constraint methods were locked in the inheritance hierarchy of a Space, then they would look inherently different from what a user could do. The fact that the constraint methods all take a Space as the first argument is due to the fact that you want to tell the constraint where it is supposed to live. There is another reason that we decided to have the constraint methods as static imports: readability. The largest part of a Gecode/J model is usually the set of constraints that are posted. While Java has some inherent problems in this area (no operator overloading), at least the symbolic constraints look fairly clean. Compare with Choco 2 (http://www.emn.fr/x-info/choco-solver/doku.php), a pure Java CP-system, that uses static imports also for the modeling part. I've seen libraries where modelling is done by directly constructing objects for the constraints. These kinds of models are usually not very readable. > - You provide Iterator<> access to search results (neat), but I can't see > an Iterable<> (I may have missed this). In general, prefer Iterable<> to > Iterator<> where possible (despite the extra work on your part) because it > fits in better with the "for ( : )" syntax: > for (Foo foo: foos) { ...foo... } > rather than > while (foos.hasNext()) { ...foos.next()... } See http://www.gecode.org/gecodej/javadoc/org/gecode/DFSIterator.html. We use the new for-loops ourselves. > - There seems to be something a bit odd with requiring a copy constructor > in subclasses of Space. Couldn't you make the type be something like > Space<C extends Space<C>> and then have an abstract method that returns C? > (called clone or copy or whatever you haven't already used). Having a > (poorly documented - by defn, since there are no Javadocs...) constructor > convention that uses ideas from C++ ("copy constructor" is not a Java > idiom) isn't a great idea. As for any type of complex class that needs to be copied, the author of that class must ultimately decide what needs to be copied. The copy constructors cannot be made generic, since the variables that need to be updated in a Space subclass must be updated there. Originally, one had to implement a copy-constructor and a copy-method (Space.copy(Boolean share), as is needed in C++), but we eliminated the copy-method in Java and replaced it with a generic copy-method that uses reflection. > I guess this looks like one big moan, but this is a really useful piece of > software and I am only trying to suggest things that might help make it > more popular... I'm not sure what your intended use of Gecode(/J) is, but if you want to model something complex or something that is very to solve, I would encourage you to try out Gecode in C++ also. The modeling support is much better, as is the efficiency. Cheers, Mikael -- Mikael Zayenz Lagerkvist, http://www.ict.kth.se/~zayenz/ _______________________________________________ Gecode users mailing list [EMAIL PROTECTED] https://www.gecode.org/mailman/listinfo/gecode-users
