RE: Scriptometer: measuring the ease of SOP (Script Oriented Programming) of programming languages

["Anton van Straaten" <address@hidden>]

> >         someCollection.find(new UnaryPredicate() {
> >                 public boolean apply(Object elem) {
> >                         return elem.someProperty() == someMatchValue;
> >                 }});
> >
> This sort-of-works in Java.  If you're used to letting anonymous
> functions close over anything they can see in the current lexical
> environment, Java will surprise you when the compiler tells you it can't
> close over non-final variables.

True - in fact I complained about this in a message on this list in May.
But in practice, it's possible to deal with this by treating Java as a
selectively pure functional language and making final everything you need to
access from within the anonymous closure.  One feature that helps with this
is that Java allows the parameters of an enclosing method to be declared
final, even if the method has a prototype (interface or parent class) that
does not do so.

> Supposedly the reason for this restriction has something to do with
> threads - without it, threads would need full access to non-local
> lexical environments.

Interesting, I didn't know the reason.

I noted in May that IBM's Jikes (1.14) compiler actually permits code which
modifies the values of external final variables from within an anonymous
closure.  Sun's compiler refuses to compile such code.  However, compiled
with Jikes, Sun's JVM (v1.3.1) will run the "illegal" code successfully,
happily mutating final variables.  I wonder how that would work with
threads??

Anton