Friday, November 29, 2002

Blocks vs. Functions There's been a bit of writing on blocks lately.  I think blocks are cool, but I'd much rather see a more general purpose functional construct added to Java.  In functional languages you have the notion of a thing that returns a value of a given type.  This is really handy for doing, well, just about everything.  It's desperately missing from Java. class ACollection {    // Declares a function signature...pretty much like a typedef    public int function WorkOn(Object parm);    // Shows how we can declare a function that takes another function    // as an argument    public int function SecondOrder(Object testMe, WorkOn work);    // Declares a function that takes another function as a parameter    public int apply(WorkOn work)    {       int total = 0;       for (int i = 0; i < array.length; i++) {          total += work(array[i]);       }       return total;    }    // These should be call compatible -- the compiler should be    // able to automatically make this work.    public int memberWorkOn(Object parm)    {       // do something with parm       return 4;    }    public void printer()    {       int total = apply( function WorkOn(Object parm) {          System.out.println(parm);          return 1;       } );       System.out.println("Total is " + total);       // Can also do this:       total = apply(memberWorkOn);    } } That's just off the cuff; don't put too much stock in it.  The point is that functions are first order objects that can be passed around like any other.  Note that there are two kinds of functions: Those that stand alone, and those that are really member functions of an object.  Back in the day Delphi had both kinds -- the combination of a this pointer and a function pointer was called a closure.  If we're going to do something like this in Java we need to have seamless support for something similar; that's the point of the memberWorkOn you see above.  The compiler can either generate the necessary closure, or create a simple one-time stub function that knows how to call the object. When creating a new function inline we will really want to have the context that surrounds the function available to us.  What is the best behavior to have here?  The only thing I can think of that will really work is to provide a copy of the functions context.  Can we really have the function block doing things that will modify the context it comes from?  That's a pretty big can of worms.  A copy means that we don't have to worry too much about it.  Or, we can just check for the variables that are actually used by the inline function, and make sure those are initialized correctly.  A change to any of those variables is not reflected in the surrounding environment. 3:43:43 PM

On java.blogs. Here are a few thoughts. Communities that grow as quickly as this one has are in dire need of organizing mechanisms. There's quite a bit of information showing up on java.blogs already, and not all of it is related to Java. I'd like to encourage those who can to create a separate channel that consists solely of their Java-related content. Radio Userland makes it easy. I'm a big believer in the promotion of ideas of merit. Some form of scoring or rating system would be a great addition to java.blogs. It doesn't have to be particularly sophisticated -- just allow users to tag the blogs that they find particularly good, and the cream will come to the top. Provide separate feeds for the top, middle, and bottom tier blogs. It's not that I think poorly of what I've seen: I just think that the megaphone has to be earned. There is clearly some good thinking going on...let's highlight it! Thanks to the Atlassian guys for making the effort to set all this up. 9:14:10 AM