> I know that all Java GUI libraries can be used within the REPL, but it is my > understanding that in order to make it self-contained and executable (a jar > or a class file), it is necessary to write some Java and call the Clojure > code from the java applet or application. Is this true, or am I doing it > wrong?
If you have a Clojure namespace that uses gen-class, and if there is a method called '-main' within that namespace, then the resultant *.class file is equivalent to a Java class with a 'main' method, and you can invoke it in the same way. See http://clojure.org/compilation for an example. > Another question I have has to do with the applet model and mutable state. > It seems like an applet's required architecture forces you to do things less > idiomatically and make use of globally defined agents or refs that change. > To give an example from the applet I am writing (but this is general across > almost all applets I would think), the paint function in Clojure (called by > the paint method of the java applet) receives a graphics object. Meanwhile > the mouseDown function receives the coordinates of the pointing device, does > something, and calls repaint. Mousedown function therefore is expected to > modify some globally defined state so that repaint can use it in > repainting. Would I be wrong to assume that this forces a > Clojure-unfriendly structure onto the Clojure applet? > > So if I am right about these two facts, it seems like Clojure should include > a native way of making applets/applications that both enables the truly > functional style that Clojure is built on, and doesn't require writing Java > to call it (it seems like Clojure should replace Java, not perpetuate it, > other than to build on its vast libraries, IMHO). What do you think (and is > there something I'm understanding wrong here)? Maybe I'm misunderstanding what you're asking, but isn't this an inherently stateful scenario? IO is always stateful, and the concept of "painting", whenever I use it, is to render the current application state to the screen. For example, I'm writing a word processor in Clojure and QT. My paint function, quite simply, takes the current state of the document and renders it to the screen. My input functions, on the other hand, modify the state of the document and then send an asynchronous notification that the document state has changed. I find this to be a quite logical breakdown of responsibilities. Sure, its not purely functional, but again, IO can never be. Also, keep in mind that although Clojure data structures are purely functional and immutable, when you're doing a GUI you're dealing with Swing Java objects which keep around quite a lot of state. But it still works quite nicely in Clojure. Clojure provides a very nice mix of purity and practicality. All my functions for logic and data manipulation are pure, but it is no trouble to reach out and mutate state (in my case, Java Objects) when I need to. I can be quite explicit about what I'm doing, and isolate my side effects in a very controlled way. Hope that helps, -Luke --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
