Last updated : 30/11/2002; 17:24:13

Joe's Jelly

Joe Walnes rambling on and on about Software Development, Java and Extreme Programming.



xp developer wiki
c2 xp wiki
the server side
sd magazine

Ara Abrahamian
Mathias Boegart
Mike Cannon-Brookes
Paul Hammant
Aslak Hellesøy
Darren Hobbs
Patrick Lightbody
Charles Miller
Brett Morgan
Rickard Öberg
Joseph Ottinger
Mike Roberts
Chris Stevenson
James Strachan

SiteMesh C++
Jelly MockTags
November 2002
Sun Mon Tue Wed Thu Fri Sat
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Oct   Dec

Click here to visit the Radio UserLand website.

Click to see the XML version of this web page.

:. 30 November 2002

  5:24:00 PM  

On adding closures to Java, Ross Judson writes:

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);

   // 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) {
         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. [Ross Judson: Java Etc.]

I think we're really getting at a similar thing : blocks and function pointers (and inner classes to a certain arguable extent) are closureish.

C# has a similar system (delegates) that allows member functions to be defined, however it doesn't support the notion of inline functions (shame).

  3:29:58 PM  

Jon Tirsen hits the nail right on the head here!

Persistence is only complicated because we make it complicated. Somewhere back in time, it was drilled into our heads that we must use relational databases for persistence. For many applications this makes a lot of sense, but the complications it adds to every day development is just sometimes not worth the effort. Huge advances have been made in the Java world in O/R persistence tools such as JDO and Hibernate (.NET still has some catching up to do here) but using a relational database is just a major headache sometimes.

When designing an application using a bottom-up approach, the database schema seems like the starting point. What is my data-model? What tables will I need?

However, taking a top-down approach (such as that encouraged in many agile processes and test-driven development) often reveals something very different. I need my app to do something - what's my test? What's the implementation? Is the test passing yet? Now I need this to be persisted - what's my test? What's the simplest thing to do persist this object? Serialization? Test passes.

Taking this approach to persistence leads to applications that are no more complicated than if the whole app runs in memory. Once again, we can focus on what the requirements are, how we can test these and plain ol' objects (poos). Focus on what the app needs to do, not what the data model looks like.

I'm often caught raving about the needs for a superly spanking O/R persistence layer (I'm even involved in building one). If a rdbms must be used, then this is essential. However actually using an rdbms is something I'd only use when absolutely necessary (or when someone else has made the decision).

I'm not ruling out the need for relational databases - I'm just noting that there are many cases when they cause more harm than do good. Of all the applications I've been involved with I'd say less than 10% that used rdbms have really needed them.

Web-design by John Doe from open source web design.