I’ve been watching some posts go by discussing the volatile keyword.

Two observations.

(1) In C and Java, the volatile keyword means “make sure changes to this variable are read and written out from the actual variable.”

I’ve seen people suggest what this means is that if you don’t mark a variable volatile, then its value is only accessible to the thread writing that variable, or some such nonsense.

Not quote.

Volatile is essentially a hint to the optimizer, indicating that once the code point hits a statement to either read or write to the specified variable, the memory holding that variable should be accessed rather than optimizing out the read or write access.

For example, suppose I have the following bit of code:

public class A
{
    int x;
    
    public void test()
    {
        for (x = 0; x < 10; ++x) {
            System.out.println("Item " + x);
        }
    }
}

(Yes, this is a dumb, contrived example.)

A reasonable optimizer could write out the following (equivalent) instructions:

public class A
{
    int x;
    
    public void test()
    {
        for (int _tmp = 0; _tmp < 10; ++_tmp) {
            System.out.println("Item " + _tmp);
        }
        x = 10;
    }
}

In other words, rather than go through the hassle of generating a global access every time we look into ‘x’ (which is a relatively expensive operation), we could simply use a local stack variable (whose access is significantly faster), iterate through the loop, then slam the global variable x to 10 at the end of the routine.

What volatile says, however, is “don’t skip read/write access for this variable; it could change independently of the current instructions being executed in this thread.” In our example above, if we were to declare ‘x’ volatile:

public class A
{
    volatile int x;
    
    public void test()
    {
        for (int x = 0; x < 10; ++x) {
            System.out.println("Item " + x);
        }
    }
}

Then we’re telling the compiler on every access of the variable: when we set it to 0 at the start of the loop, when we increment it, and when we test to see if it is less then 10, and when we print it out–each time we should always go directly to the global variable. No fair using a local variable to speed things up. The optimization above, in other words, is illegal when x is marked volatile.

Of course this is a completely contrived example; in the real world you wouldn’t use a field for a for loop. But you may want to access a class variable and use it in a rather complex way while guaranteeing that within your method access to that variable isn’t optimized out for whatever reason–and volatile guarantees that for you.

(2) Java 5 and greater also adds an additional semantic to volatile: reads and writes to the variable are guaranteed to be atomic. What this means is simple: suppose you’re writing a long integer:

	long i = 5;

The underlying processor may be a 32-bit processor, which means that the underlying CPU must actually do something like:

	int i_0 = 0;		// the first 4 bytes
	int i_1 = 5;		// the last 4 bytes

In other words, the assignment ‘i = 5’ actually requires two processor memory write operations.

Now suppose we have a task swap take place between the first write and the second. Then what happens is that only half of our long integer has been updated, and the other half may contain garbage. So in the following contrived example:

	long i = -1;
	// some time later...
	i = 0;

A read from the variable i could, in theory, return more than just -1 and 0: it may also return 0xFFFFFFFF00000000 or it could return 0x00000000FFFFFFFF, depending on the order the 32-bit words are written.

If i is only allowed to be -1 or 0, well, you can see how you could have a problem.

By guaranteeing that the reads and writes are atomic, however, Java guarantees that both words are written before we attempt to read either. In other words, by declaring i volatile we do the equivalent of:

    synchronized(_semaphore) {
        int i_0 = high_word;
        int i_1 = low_word;
    }

(Though the semaphore Java uses is significantly faster.)

This means we’ll never see 0xFFFFFFFF00000000 or 0x00000000FFFFFFFF in our contrived example, if we only declare i as volatile, with Java 5 or later. (Java 1.4 or earlier, however, does not guarantee atomic read/write semantics, which means you must wrap the variable in a semaphore.)

It’s important to be aware of these issues and carefully craft your code with a full understanding of the ramifications of your code. Otherwise you may wind up with a multi-tasking application which, on a very rare (and damned hard to find occasion) just randomly fail for no good reason.

I will admit this post was inspired by How would you write factorial(n) in java? So excuse me while I rant in code: I have a point to make at the bottom of this article.

Now most people who write factorial in Java may start with something simple, like:

    public static int factorial(int n)
    {
        if (n == 0) return 1;
        return n * factorial(n-1);
    }

Wrapping this in a class (since we’re talking about Java, of course), they may write it inside a utility class. For example:

public class FactorialUtil
{
    public static int factorial(int n)
    {
        if (n == 0) return 1;
        return n * factorial(n-1);
    }
}

Simple, no?

There is a non-recursive solution as well:

public class FactorialUtil
{
    public static int factorial(int n)
    {
        int ret = 1;
        for (int i = 1; i <= n; ++i) ret *= i;
        return ret;
    }
}

Now the observent reader may note “gosh, it’s entirely possible the value will be longer than an integer”, so they’ll perhaps rewrite in terms of BigInteger or at least in terms of long, depending on the requirements of the program. Thus:

public class FactorialUtil
{
    public static BigInteger factorial(int n)
    {
        BigInteger ret = BigInteger.ONE;
        for (int i = 1; i <= n; ++i) ret = ret.multiply(BigInteger.valueOf(i));
        return ret;
    }
}

Notice that thus far, of course, I’ve made no use the fact that I’m constantly recalculating the intemediate values from 1 to n. If those values were cached, of course, I could save myself a lot of computations. One way to do this is to use recursion, but if we’ve already calculated the value, store it away for future use. Thus (using HashMap, because it’s there), we get:

public class FactorialUtil
{
    static HashMap<Integer,BigInteger> cache = new HashMap<Integer,BigInteger>();
    
    public static BigInteger factorial(int n)
    {
        BigInteger ret;
        
        if (n == 0) return BigInteger.ONE;
        if (null != (ret = cache.get(n))) return ret;
        ret = BigInteger.valueOf(n).multiply(factorial(n-1));
        cache.put(n, ret);
        return ret;
    }
}

Easy enough, right?

Now each of these different methods entail different tradeoffs, and given that we may wish to reuse this library in the future, perhaps what we want to use is a technique routinely used in other Java libraries: a pluggable mechanism that allows us at runtime to decide which technique (the slower but small memory footprint technique, or the more memory intensive, but faster technique). So first, we need to refactor our class as a singleton, because pluggable things require instantiated classes and a default singleton class to implement the default mechanism.

So we create a class whose job it is to maintain a singleton for our factory class, and a reference to the algorithm that actually implements our method. This class provides the old interface we have from above, but defers to a separate (and new and improved!) algorithm engine:

public class FactorialUtil
{
    private static FactorialUtil singleton;
    private FactorialAlgorithm algorithm;
    
    /**
     * Default (internal) constructor constructs our default algorithm.
     */
    private FactorialUtil()
    {
        algorithm = new CachedFactorialImplementation();
    }
    
    /**
     * New initializer which allows selection of the algorithm mechanism
     * @param algorithm
     */
    public FactorialUtil(FactorialAlgorithm a)
    {
        algorithm = a;
    }
    
    /**
     * Default public interface for handling our factorial algorithm. Uses
     * the old standard established earlier for calling into our utility class.
     * @param n
     * @return
     */
    public static BigInteger factorial(int n)
    {
        if (singleton == null) {
            // Use default constructor which uses default algorithm
            singleton = new FactorialUtil();
        }
        return singleton.doFactorial(n);
    }

    /**
     * New mechanism which allows us to instantiate individual factorial
     * utilitiy classes and invoke customized factorial algorithms directory.
     * @param n
     * @return
     */
    private BigInteger doFactorial(int n)
    {
        // Defer to our algorithm
        return algorithm.factorial(n);
    }
}

Notice the above class is now responsible for creating the singleton and deferring to the algorithm class. We even have a private initializer which initializes to any algorithm, and a way to create an instance which uses the algorithm we select.

This all depends on an algorithm interface:

public interface FactorialAlgorithm
{
    BigInteger factorial(int n);
}

And here is our cached factorial implementation referred to from above:

public class CachedFactorialImplementation implements FactorialAlgorithm
{
    static HashMap<Integer,BigInteger> cache = new HashMap<Integer,BigInteger>();
    
    @Override
    public BigInteger factorial(int n)
    {
        BigInteger ret;
        
        if (n == 0) return BigInteger.ONE;
        if (null != (ret = cache.get(n))) return ret;
        ret = BigInteger.valueOf(n).multiply(factorial(n-1));
        cache.put(n, ret);
        return ret;
    }
}

Look how beautiful this structure is! I mean, we can also add a non-caching non-recursive algorithm easily:

public class LoopedFactorialImplementation implements FactorialAlgorithm
{
    @Override
    public BigInteger factorial(int n)
    {
        BigInteger ret = BigInteger.ONE;
        for (int i = 1; i <= n; ++i) ret = ret.multiply(BigInteger.valueOf(i));
        return ret;
    }
}

The weakness of this design from a Java perspective should be obvious: it does not allow us to select the algorithm we wish to use at runtime, which was a major design feature we were striving for. (I mean, after all, if our new program has different constraints, we should be able to select the specific algorithm used, right?) So clearly we need to load a configuration property and select the algorithm we want. We can do this by having our utility class look in the System properties, for example, which has the nice property that we can then, higher up, wire up to an external interface as needed. Ideally our main method would look like:

    public static void main(String[] args)
    {
        System.getProperties().setProperty("com.chaosinmotion.factorialalgorithm", "cachedAlgorithm");
        System.out.println("5! = " + FactorialUtil.factorial(5));
    }

This implies that we need a hash map of algorithms that we pick from prior to creating our singleton inside the factorial method.

So we need a factory that can generate the algorithms. We store both a map of instantiated factory singletons by name in mapping, and we store the class references in classMapping, so we don’t create the algorithm class until we actually need it. (No point in running a bunch of constructors and allocating resources we don’t use.)

/**
 * Factory class manages the factorial algorithms in our system.
 * @author wwoody
 *
 */
public class FactorialAlgorithmFactory
{
    private static HashMap<String,FactorialAlgorithm> mapping = new HashMap<String,FactorialAlgorithm>();
    private static HashMap<String,Class<? extends FactorialAlgorithm>> classMapping = new HashMap<String,Class<? extends FactorialAlgorithm>>();
    private static FactorialAlgorithm defaultAlgorithm = new CachedFactorialImplementation();
    
    /** Static initializer registers some of my known classes */
    static {
        try {
            Class.forName("com.chaosinmotion.factorial.LoopedFactorialImplementation");
            Class.forName("com.chaosinmotion.factorial.CachedFactorialImplementation");
        }
        catch (ClassNotFoundException e) {
            // Should never happen.
        }
    }
    
    /** Get the default algorithm for computing factorials */
    public static FactorialAlgorithm getDefaultAlgorithm()
    {
        if (defaultAlgorithm == null) {
            // Warning: this will fail if for whatever reason CachedFactorialImplementation
            // is not in the class path.
            defaultAlgorithm = getAlgorithm("cachedAlgorithm");
        }
        return defaultAlgorithm;
    }
    
    /** Get the factorial algorithm specified by name */
    public static FactorialAlgorithm getAlgorithm(String name)
    {
        FactorialAlgorithm f = mapping.get(name);
        if (f == null) {
            // We haven't created an instance yet. Get it from the class mapping.
            Class<? extends FactorialAlgorithm> c = classMapping.get(name);
            if (c != null) {
                // Create a new instance of the factorial algorithm specified
                try {
                    f = c.newInstance();
                    mapping.put(name, f);
                    return f;
                }
                catch (Exception e) {
                    // Log the error
                    Logger.getLogger("com.chaosinmotion.factorial").
                    warning("Unable to instantiate algorithm " + 
                            c.getCanonicalName() + ", named " + name);
                }
            }
            return getDefaultAlgorithm(); // return something.
        }
        else return f;
    }
    
    /** Register the class so we can construct a new instance if not already initialized */
    public static void registerAlgorithm(String name, Class<? extends FactorialAlgorithm> f)
    {
        classMapping.put(name, f);
    }
}

Rewriting our FactorialUtil class to use our named algorithms instead, we get:

public class FactorialUtil
{
    private static FactorialUtil singleton;
    private FactorialAlgorithm algorithm;
    
    /**
     * Default (internal) constructor constructs our default algorithm.
     */
    private FactorialUtil()
    {
        String name = System.getProperty("com.chaosinmotion.factorialalgorithm", "cachedAlgorithm");
        if (name == null) {
            algorithm = FactorialAlgorithmFactory.getDefaultAlgorithm();
        } else {
            algorithm = FactorialAlgorithmFactory.getAlgorithm(name);
        }
    }
    
    /**
     * New initializer which allows selection of the algorithm mechanism
     * @param algorithm
     */
    public FactorialUtil(FactorialAlgorithm a)
    {
        algorithm = a;
    }
    
    /**
     * Utility to create by name. Calls into FactorialAlgorithmFactory to
     * actually get the algorithm.
     * @param name
     */
    public FactorialUtil(String name)
    {
        algorithm = FactorialAlgorithmFactory.getAlgorithm(name);
    }
    
    /**
     * Default public interface for handling our factorial algorithm. Uses
     * the old standard established earlier for calling into our utility class.
     * @param n
     * @return
     */
    public static BigInteger factorial(int n)
    {
        if (singleton == null) {
            // Use default constructor which uses default algorithm
            singleton = new FactorialUtil();
        }
        return singleton.doFactorial(n);
    }

    /**
     * New mechanism which allows us to instantiate individual factorial
     * utilitiy classes and invoke customized factorial algorithms directory.
     * @param n
     * @return
     */
    private BigInteger doFactorial(int n)
    {
        // Defer to our algorithm
        return algorithm.factorial(n);
    }
}

And we have to modify our CachedFactorialImplementation and LoopedFactorialImplementation to include static class initializers which register those classes with my factory:

public class CachedFactorialImplementation implements FactorialAlgorithm
{
    static HashMap<Integer,BigInteger> cache = new HashMap<Integer,BigInteger>();
    
    static {
        FactorialAlgorithmFactory.registerAlgorithm("cachedAlgorithm", CachedFactorialImplementation.class);
    }
    
    @Override
    public BigInteger factorial(int n)
    {
        BigInteger ret;
        
        if (null != (ret = cache.get(n))) return ret;
        ret = BigInteger.valueOf(n).multiply(factorial(n-1));
        cache.put(n, ret);
        return ret;
    }
}

and

public class LoopedFactorialImplementation implements FactorialAlgorithm
{
    static {
        FactorialAlgorithmFactory.registerAlgorithm("loopedAlgorithm", LoopedFactorialImplementation.class);
    }
    @Override
    public BigInteger factorial(int n)
    {
        BigInteger ret = BigInteger.ONE;
        for (int i = 1; i <= n; ++i) ret = ret.multiply(BigInteger.valueOf(i));
        return ret;
    }
}

The beauty of this architecture, of course, is that we can even add in our own custom algorithm and plug it into the singleton underlying FactorialUtil. We simply create our new FactorialAlgorithm implementation, registering our class with the FactorialAlgorithmFactory class during static class initialization:

public class RecursiveFactorialImplementation implements FactorialAlgorithm
{
    static {
        FactorialAlgorithmFactory.registerAlgorithm("recursiveAlgorithm", RecursiveFactorialImplementation.class);
    }

    @Override
    public BigInteger factorial(int n)
    {
        if (n == 0) return BigInteger.ONE;
        return BigInteger.valueOf(n).multiply(factorial(n-1));
    }
}

and in our main routine, we make sure our class is loaded, then we set the property to specify we use our new algorithm.

    public static void main(String[] args)
    {
        try {
            Class.forName("com.chaosinmotion.factorial.RecursiveFactorialImplementation");
        }
        catch (ClassNotFoundException e) {
            // if this fails, no matter; we'll still use the default implementation.
        }
        System.getProperties().setProperty("com.chaosinmotion.factorialalgorithm", "recursiveAlgorithm");
        System.out.println("5! = " + FactorialUtil.factorial(5));
    }

No problems! And the architecture even lends itself to our plugging in more ingenious solutions, such as the algorithms documented here.

Now I’m sure at this point there are a number of Java programmers reading this who are nodding their heads at how cool all of this mechanism is. There are a few, of course, who are about to hit the comment button and say “gosh, instead you should wire up the properties this way, or that way…” For example, I could have put the initializer for the different class mappings into a properties file that is part of the package, or as an XML file. Or perhaps I could have set the property to accept the class name explicitly; that way I could have the FactorialAlgorithmFactory do the ‘forName’ call and instantiate the class directly without having to look it up in two hash maps.

And I’m sure there are a few programmers out there taking notes or even cutting and pasting the above blocks of code. (Yes, I tested it all; it works on my system, though I don’t claim to have done the cut and paste properly in all cases.)

But here’s my point.

It’s all crap.

Every last line of it.

Sure, there are circumstances where a pluggable architecture would be desirable or even necessary–but that comes up so rarely it’s not even funny. About 99% of the time I see code like this, it’s completely and utterly useless. It’s obscuring the purpose of the code–replacing a two or three line utility (max!) with dozens or even hundreds of lines of self-important masturbatory Java bullshit. Sure, it may make you feel good–but it makes an ugly mess of it that future developers will have to clean up, or more likely just avoid like the plague.

And, worse, in the entire discussion, did you notice something?

We never handled negative numbers.

The smart Java developer would know when to stop. Life is too short to build castles in the clouds. He’d know that a simple looped solution is more than sufficient, and of course he handles negative numbers. (Note that in our recursive solutions, a negative number results in an endless loop.)

The really smart Java developer figures out the domain of the problem set, knowing (for example) that factorial is actually a special subset of the Gamma function. Perhaps the right answer isn’t any of the code above; perhaps the right answer is using Gergo Nemes’s approximation to Stirling’s approximation to the Gamma Function:

    static double Gamma(double z)
    {
        double tmp1 = Math.sqrt(2*Math.PI/z);
        double tmp2 = z + 1.0/(12 * z - 1.0/(10*z));
        tmp2 = Math.pow(z/Math.E, z); // ooops; thanks hj
        tmp2 = Math.pow(tmp2/Math.E, z);
        return tmp1 * tmp2;
    }

But it depends on the domain: a domain we only second-guessed in all of our factory creation/algorithm interface bullshit above.

The biggest complaint I have with many Java developers is that they develop a whole bunch of really bad habits. Specifications are unclear, or they think someday the code may need to be extended into a different direction. So they write a whole bunch of overblown architectural nonsense, sight unseen, thinking that the additional crap someday will help out and make things easier. And Java as a language lends itself to doing this very quickly and easily, so that (as the theory goes) it’s easy for us to build architectures that will someday make it easier on us in the future.

But the future never gets easier, does it?

Because a year from now they wade through all this excess baggage written at a time when they thought they understood the domain of the problem (but clearly didn’t), instead of having simple code (like the very first example of factorial above) that they can revise as needed, they wind up with the most over-engineered pile of nonsense that no-one can possibly understand.

And rather than wade into the mess to untangle the knot, or at least understand the mechanism that was put into place, they just plaster over the problem in a classical example of the lava flow anti-pattern. Perhaps they don’t understand how to create a pluggable algorithm, so instead they override the FactoryUtil class, or they simply create a new FactoryUtil class instead–and add hundreds more lines of (ill-conceived) code to plaster over the lack of understanding of the hundreds of existing lines of (ill-conceived) code.

So please, do us all a favor: if you have the urge to add complexity because “someday we’ll need it, I just know it!”, or because “it’s not sufficiently flexible enough” or “we need reusability in our code” or (God help us!) because it’s “cool”–just go home early. Watch some cartoons. Rent Inception on DVD.

And stop creating extra work for us in the future for no good reason.

Two observations about the whole Apple deprecating Java thing:

(1) One of the biggest problems with Java on the Macintosh is that the Java AWT/Swing stuff is just bloated like crazy. I like Java Swing and the Mac implementation a lot; I have written Macintosh applications in Java that look and feel like Macintosh applications.

But practically speaking it’s just crazy bloated–and I would have been just as happy with something significantly smaller. (Do you really need pluggable LAF libraries? Has anyone you known ever successfully extended the javax.swing.plaf abstract classes to build their own custom look and feel? And would you really want to in the first place?)

The engineering cost is just not worth it.

Had Sun made portability a substantial requirement: require, for example, that the OpenSDK can be ported to a new windowing environment with less than a few months of one engineer’s time, by simplifying the native dependencies, for example, we wouldn’t be here.

(2) Of all the companies in the world right now using Java, Google is the one company that is doing the most interesting things: they’ve created their own VM for Android, they’ve created a Java to Javascript cross-compiler in GWT. They seem to be the most devoted to creating a useable subset of Java that allows you to write once (in Eclipse) and run anywhere (on mobile devices, desktop, web browsers).

If people really want Java to survive, they’d petition Google to purchase the assets behind Java. And let Google maintain Java and extend it into a full-fledged open language.

There are, in my opinion, four basic language features in Java which make the language extremely cool–in that they allow IDE developers and software developers to quickly and easily deploy tools which make working with Java very easy.

I wanted to point out these features in the hope that future languages (or future extensions to other existing languages such as C++ or Objective C) could incorporate these features, in order to make those language ecosystems better overall.

Now there are a lot of things that are cool about Java. The standard RTL, so there is a standard way to create multiple threads, do file I/O, networking or other similar things is quite cool. (I’m used to the days of early versions of Pascal or C where it was anybody’s guess how to do these things.) But in my estimation the following four features have made the overall Java ecosystem quite friendly compared to other languages.

1. Reflection.

Java’s reflection system is quite complete, allowing full introspection for any given object of the class of that object, the interfaces it implements, the base class it extends, the methods it implements and the fields that are contained in that class. With methods you can introspect the parameters and the return values. You can even dynamically, using the reflection system, construct objects on the fly and invoke methods on the fly.

Java’s reflection system is far more powerful than similar systems in Objective C (which, by design, cannot really allow introspection of the methods implemented by a class, since methods are just messages and there is no strong association of implemented messages), or in C++ (which really only allows you to discover the class of an object, and that’s it.)

Later versions of Java even provide an annotation mechanism by which classes can be annotated or marked with special flags, so during introspection different classes can be handled in different ways.

This level of reflection allows one to construct a complete dynamic serialization library, serializing and deserializing objects without ever needing the object to know what is being done to it.

And because the reflection information is contained (as a first class, well documented data structures) inside a compiled .class file, it is not all that difficult to compile a Java file, then introspect the .class file and provide information about that class. By using this it is possible for an IDE to automatically determine, for example, which methods in an abstract class need to be implemented by a child class, and automatically write the missing method calls for you. I suspect in fact this is how the Eclipse functions to create a new class, populating the methods that need to be implemented, is performed.

I use that all the time.

2. Proxying.

Java also has the ability to, given an interface class declaration, create a proxy class which provides an implementation of that interface, redirecting the method calls to another object.

Proxying is a very powerful mechanism which allows remote procedure calls to be implemented with just a few lines of code. Proxying also allows other very powerful techniques to be implemented, such as using interface methods to define the constant values in a property file, and automatically associate variables in a dynamically loaded configuration file.

While proxying is a bit of a one-trick horse, it provides a tremendous amount of power that, combined with reflection, allows you to do RPC without having to create a RMI language specification and compiler to build the client and server components. You can infer the parameters with reflection and redirect with proxying.

3. Exception Stack Introspection.

Of course most languages have exceptions. What makes Java really cool is the ability to dump the function call stack when an exception is thrown. This is an extremely powerful mechanism because it allows you to know precisely what was thrown and where it was thrown from. And most of the time, knowing what happened and where gives you a huge clue as to why something went wrong.

In fact, I’d say the biggest mistake I’ve ever seen a Java programmer make is to re-throw an exception without setting the cause parameter of the re-thrown exception. For example, I’ve seen the following:

try {
    // A whole bunch of complicated crap with calls
    // into thousands of lines of error-prone methods.
    ...
}
catch (Exception someException) {
    throw new StandardException("All hell broke loose.");
}

Then I see the following:

com.chaosinmotion.mything.StandardException: All hell broke loose.
	at com.chaosinmotion.mything.Test.doSomething(Test.java:19)
	at com.chaosinmotion.mything.Test.main(Test.java:32)

And I want to murder the developer who couldn’t be bothered to add an ‘initCause’ call to the rethrown exception.

4. Inner classes and anonymous classes

To me, these both have the same net effect: they give the developer the ability to define a class inside another class, which has access to the parameters of the outer class, which can then be used as a form of closure. And closures are cool because they allow a callback function or method invocation to have access to the immediate lexical environment where the functioning requiring the closure to be invoked.

For example, suppose we have a method call that takes an interface, where the method in that interface is called for each list of objects in a system:

    private interface Callback
    {
        void object(Collection l);
    }

    private void getAllObjects(Callback callback)
    {
        ....
    }

We can gather up all of the objects in a single list using an anonymous inner class in a function call:

    private List gatherAll()
    {
        final ArrayList n = new ArrayList();
        
        getAllObjects(new Callback() {
            public void object(Collection l)
            {
                n.addAll(l);
            }
        });
        
        return n;
    }

While Java’s implementation of anonymous functions may not meet the strict criteria of closures, in that you do not get full read/write access to all the stack variables within the function where the anonymous class is declared (thanks to the Funarg Problem), read-only access to mutable objects gets us close enough that it doesn’t really make much difference.

Closure-like functionality is such a cool language feature that Apple added it to the latest version of Objective C. Something like the above could be done by declaring a method -getAllObjects: which takes a block–a reference to a function with closure:

	- (void)getAllObjects:(void (^)(NSArray *))callback;

Then calling it with a block that accumulates the results:

    - (NSMutableArray *)gatherAll
    {
        NSMutableArray *n = [[[NSMutableArray alloc] init] autorelease];

        [self gatherAllObjects: ^(NSArray *param) {
            [n addObjectsFromArray:param];
        }];

        return n;
    }

The reason for me picking these four features is simple: I believe if other languages were extended to provide these features, then it would not only make the languages themselves more useful, but if they were provided, they would also allow the ecosystem of IDEs and compilers to become more useful as well. Reflection is extremely important to the ecosystem of IDEs: by being able to parse some sort of data structure during development that gives full inspection of the various components of a class or collection of function calls, it would make automatic code generation far easier to create. Better yet, if compilers for a given language could standardize on an intermediate “story of your compile” like structure that also gives line numbers for compiled objects (as is provided in Java class files with debugging turned on), it would make it extremely easy to automatically generate code on the fly during development.

And every language has an undue amount of bookkeeping stuff that needs to be written which make those languages cumbersome to use. C++, for example, requires all methods to be described in two separate places: once in the header file, and again with the method code. Imagine an IDE which could automatically generate the code declarations based on the header declarations, leaving you to only fill in the blanks. Or an IDE which could automatically add the required methods from the abstract class method declarations in an abstract C++ class.