Limitations of Java Java Classes Compared to Objective-C Blocks

I am just starting to envelop first-order and closure functions after detecting blocks in Objective-C. Java is another language in which I heard about closure (or lack thereof) and how anonymous classes do it.

I can definitely see the benefits of closures as blocks in Objective-C, but what are the limitations of anonymous Java classes? To what extent do they “somewhat” compensate for the absence of true closures?

+6
source share
2 answers

Java anonymous classes are really, really verbose. Besides the sheer number of templates that you only need to define them, some of the Java design decisions mean that many common tasks are much more verbose than in other languages. For example, importing modified values ​​into closures is a pain in the ass in Java.

Basically, Java does not support upvalues; instead, they are modeled by passing them (by value) to the class via invisible parameters to the class constructor. Since they are passed by value, changing them inside the class will not affect the copy in the method that the class built, so the compiler forces you to declare them final to avoid confusion. eg:.

Runnable function() { final int i = 4; return new Runnable() { public void run() { System.out.println("i="+i); // can't modify i here } } } 

In cases where you need to change a variable, for example, in almost every case where closing would be useful, you should trick:

 Runnable function() { final int[] i = new int[1]; i[0] = 4; return new Runnable() { public void run() { System.out.println("i="+i[0]); i[0] = i[0] + 1; } } } 

Here i itself is still immutable, but since it points to an object to be modified, I can change the contents of the object. (Naturally, in real life, I would use a class, not an array, because using arrays is really ugly, and this makes it even more verbose.)

I understand that the next release of Java will have syntactic sugar to make it all easier, but right now, closing-based programming is pretty cumbersome in Java. It is often easier for me to change the logic so as not to use closure, just so that I can keep the amount of code used small enough to be clear.

+10
source

I really don't know about the objective-C closure version, but I know them from Smalltalk and Lua.

A closure is essentially a function that has access to the local variable of some other function / block (usually one in which the closure is syntactically nested). Thus, a local variable can live longer than the block in which it is defined. When you have multiple closures on the same variable, they can be linked using this variable.

Local Java classes (of which anonymous classes are a special case) support a limited version of this: they allow access to the final variable, that is, a variable that cannot change its value. This is accomplished by copying the value of this variable into a local class object on it. You can emulate real closures using a mutable object in this variable (in the simplest case, a singleton array).

In addition, the Java syntax for this is pretty ugly, but it fits nicely into the rest of the language and provides static type security (as opposed to the shorter syntax options discussed).

+5
source

Source: https://habr.com/ru/post/889488/


All Articles