Tipos, variables, matrices y colecciones de cierre de Java

Question

¿Cuál es el estado actual de las especificaciones para el cierre de Java?

1. En la especificación de Java cierre propuesto, habría que ser capaz de crear una matriz o colección de cierres?
   En caso afirmativo, ¿sería posible esta sintaxis?

   {int x, int y => boolean b}[] comparisonSwitch = { 
       {int i, int j => return i>j}, 
       {int i, int j => return j<i}, 
       {int i, int j => return j==i} 
   } 
   
   boolean compare(int acase, int a, int b){ 
       return comparisonSwitch[acase].invoke(a,b); 
   } 
   

2. ¿Se considerarían los métodos normales como cierres no anónimos?
   Entonces, ¿sería posible la siguiente sintaxis?

   public class Asdf 
   { 
       public boolean gt(int x, int y){ 
       return x>y; 
       } 
       public boolean lt(int x, int y){ 
       return x<y; 
       } 
       public boolean eq(int x, int y){ 
       return x==y; 
       } 
   
       {int x, int y => boolean b} GT = gt; 
       {int x, int y => boolean b}[] comparisonSwitch = { 
       gt, lt, eq 
       } 
   } 
   

3. es decir, son cierres y métodos interchangeble operacionalmente?
   ¿Se permitiría la siguiente sintaxis?

   // declare a method that has a closure type as an argument 
   void closurator({String s => int a} findlen){ 
       // do whatever 
   } 
   String s = "hello"; 
   void useClosurator(){ 
       // invoke the method by supplying a non-anonymous method 
       // of an object 
       closurator(s.indexOf(String ss)); 
   } 
   

4. ¿Cómo podemos ser capaces de especificar un tipo de cierre en una interfaz?
   Podríamos hacer lo siguiente, declarando de manera efectiva la referencia final/constante a los métodos.

   interface Closuration 
   { 
       public class Asdf 
       { 
       static public boolean gt(int x, int y){ 
        return x>y; 
       } 
       static public boolean lt(int x, int y){ 
        return x<y; 
       } 
       static public boolean eq(int x, int y){ 
        return x==y; 
       } 
       } 
   
       {int x, int y => boolean b}[] comparisonSwitch = { 
       Asdf.gt, Asdf.lt, Asdf.eq 
       }; 
   } 
   

5. Desde cierres tendrían acceso a espacio de código, al igual que la reflexión sería, usaría el cierre de ralentizar el rendimiento de un programa? De lo contrario, ¿significaría que la reflexión se aceleraría mediante los avances de los préstamos realizados en la "tecnología de cierre"?

inserta el nuevo pregunta: En realidad, habría código de cierre de formar parte del espacio de código o en el montón de variables, porque yo estoy prediciendo que el código de cierre sería susceptible de ser borrado por la recolección de basura, ¿verdad?

¿Puedo solicitar que se concentre en la esencia de las preguntas, no en cualquier sintaxis errores/errores tipográficos/palabras clave que faltan en el código de ejemplo. Cualquier error tipográfico/error, por favor corrígemelo. Gracias.

Answer 1

Estás preguntando por el JDK7 cierres de trabajo, por lo que las referencias a javac.info no son relevantes. Ese sitio trata acerca del proyecto closedjdk closures, ahora completado,, que mostró cómo agregar cierres transparentes a Java - transparencia en el sentido de que satisface el Principio de correspondencia de Tennent y se describe aproximadamente en my blog.

El esfuerzo para JKD7 se organiza bajo el openjdk lambda project. La especificación está experimentando una rápida evolución, por lo que cualquier respuesta es tentativa. Como señaló Tom Hawtin, here is the latest draft spec.

Antes de responder a sus preguntas específicas, vale la pena observar que Java tiene espacios de nombres separados para variables y métodos. En consecuencia, es probable que haya alguna distinción sintáctica entre invocar un método e invocar una variable del tipo de función (en el lenguaje C#, un delegado). Del mismo modo, es poco probable que pueda referirse a un método simplemente nombrándolo, como lo haría con un campo.

para responder a sus preguntas:

1. Esa no es la sintaxis propuesta para un tipo de función. Dejando de lado ese tema, te preguntas si será legal tener una variedad de tipos de funciones. El borrador actual de la especificación sugiere que la respuesta es sí, pero las estrategias de implementación conocidas darían como resultado un agujero en el sistema de tipos a menos que "matriz de tipo de función" no se permita de alguna manera. El borrador de la especificación evita cuidadosamente la discusión de estrategias de implementación. Es posible que los cambios en la especificación de VM puedan hacerse para solucionar estos problemas. Si tuviera que adivinar, sospecho que la respuesta a su pregunta será "no". Sin embargo, podría lograr el mismo efecto usando java.util.List en lugar de una matriz. Dado que el project Coin por separado está considerando agregar literales Collection y operaciones de indexación para List, es probable que sea tan conveniente desde el punto de vista sintáctico.
2. Te estás preguntando si crearás una expresión con valores de función nombrando un método. Debido a que (entre otras razones) los métodos y las variables aparecen en diferentes espacios de nombres en Java, la respuesta es probablemente no. Sin embargo, es posible que la especificación se extienda con una sintaxis específica para pedir que un nombre de método se trate como una expresión con valores de función. Consulte la sección Método Referencias en el documento Closures for Java (v0.6a) para una forma que podría considerarse, utilizando una sintaxis propuesta por Stephen Colebourne. Esto aún no está en ningún borrador del proyecto lambda.
3. Ver la respuesta a (2).
4. Ver la respuesta a (2).
5. Le preocupa el rendimiento. En resumen, es poco probable que los cierres se implementen con cualquier técnica que haga que sean mucho más caros de invocar que un método. No se requieren cambios de VM por motivos de rendimiento, aunque podrían ser una buena idea por otros motivos (ver respuesta a 1). Consulte the Closures Project homepage para obtener un puntero a un prototipo de BGGA, una especificación de cierres más ambiciosa, que se ejecuta en stock jdk5/jdk6, y cuyo rendimiento puede medir.

Answer 2

Cierres en JDK7 son cortos en detalle en este momento. En la presentación en Devoxx, los ejemplos utilizados fueron muy similares al FCM closures proposal.

Suponiendo que se utiliza en las especificaciones JDK7 entonces creo que la respuesta a las partes 2, 3 y 4 de su pregunta es sí (aunque bien podría estar equivocado).

Para la parte 1 - Creo que debería ser posible tener matrices ya literales método se pueden asignar a los objetos Method.

Por parte 5 Sospecharía el funcionamiento sería similar a las clases internas.

En este momento estoy siendo un poco vago - espero que ayude un poco. Probablemente aún sea temprano para responder sus preguntas con certeza.