Someone mentioned the "application context" pattern in a recent post on this list. I think that would be a great way to functionally implement GUIs in general. The idea is that new states are generated from previous ones and passed as a parameter instead of having a globally defined state that you need to alter.
On Feb 16, 11:08 am, levand <luke.vanderh...@gmail.com> wrote: > > I know that all JavaGUIlibraries 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. Seehttp://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 aGUIyou'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 -~----------~----~----~----~------~----~------~--~---
