Mecanismos de Java en uso en cierres lambdaj.

Question

Lamdbaj permite la definición de cierres en el lenguaje Java, se pueden encontrar varios ejemplos aquí

Mi pregunta es sobre los mecanismos subyacentes de Java en uso, por ejemplo, para definir el cierre de println , se usa el siguiente código:

Closure println = closure(); 
{ of(System.out).println(var(String.class)); }

Este cierre se puede ejecutar posteriormente a través de:

println.apply("foobar");

Tengo curiosidad por saber qué mecanismos en Java permitirían que la llamada a de (...). println (...) se asocie con println instancia en sí.

Naturalmente, el código fuente de lambdaj está disponible para leer, pero esperaba una explicación un poco más alta si alguien tiene una. Mis habilidades de reflexión van tan lejos como un poco de introspección y métodos de ejecución dinámicamente.

Answer 1

Bueno, of es presumiblemente un método static que se importa de forma estática para que pueda llamarse sin el nombre de la clase adjunta. Espero que var sea el mismo. Ambos métodos deben devolver algún tipo que tenga los métodos llamados posteriormente:

public class Printable {
  public void println(Var var);
}

public class Fac {
  public static Printable of(Object o) {
    return new Printable(o);
  }

  public static Var var(Class<?> clazz) {
    return new Var(clazz);
  }

} 

De repente:

Fac.of(System.out).println(Fac.var(String.class));

Es Java válido. Usando importaciones estáticas, hola presto:

import static Fac.*;

of(System.out).println(var(String.class));

Las llaves son obviamente Java válidas, ya que puedes agregarlas en cualquier método para ayudar a definir un alcance léxico. Este estilo de diseño de API se llama fluido y se muestra mejor por La JMock .

Por cierto, si se supone que esto debe introducir cierres en Java, es bastante ridículo: la sintaxis es terriblemente horrible . Su ejemplo de E / S en realidad me hizo reír a carcajadas. Prueba Scala !

EDIT : las dos llamadas println están asociadas, creo que porque la primera secuencia de llamadas permite que la biblioteca capture las variables que ha pasado como parámetros. Estos probablemente se capturan en alguna estructura de ThreadLocal . Cuando luego llama a un método (también presumiblemente estático) println , la biblioteca está utilizando estos datos capturados para ejecutar el comportamiento en un momento posterior. También relacionado con las pruebas, el marco de prueba EasyMock utiliza un mecanismo similar (que utiliza proxies Java en segundo plano) para capturar los valores esperados.

Answer 2

Soy Mario Fusco y soy el desarrollador principal de la biblioteca lambdaj.

En primer lugar, me gustaría aclarar algo: lambdaj no pretende reemplazar ningún lenguaje funcional. Como dije la semana pasada en mi discurso en el Jug of Zurich si tiene la oportunidad de usar Scala, inténtelo y nunca mire hacia atrás. Aquí puede encontrar un resumen de mi discurso donde se indica claramente que:

http://ctpjava.blogspot.com/ 2009/10 / lambdaj-new-trends-in-java.html

También soy un desarrollador de Scala feliz. Pero a veces solo estás obligado a desarrollar en Java (en mi experiencia, en el mundo real, aproximadamente el 80% de las veces que no puedes elegir en qué idioma tienes que escribir tu código) y en este caso algunas de las características de lambdaj podrían ser útil (o eso espero). Solo quería traer a Java algunas características funcionales que faltan totalmente. Por supuesto, el resultado no es completamente satisfactorio debido principalmente a la limitación impuesta por Java.

En cuanto al mecanismo interno de lambdaj, sí, utiliza un ThreadLocal para lograr ese resultado. Si tiene otras preguntas, curiosidades o incluso mejores sugerencias y críticas constructivas sobre lambdaj, quizás le interese registrarse en la lista de correo de lambdaj aquí:

http://groups.google.com/group/lambdaj

adios Mario