En un futuro próximo, aparecerán nuevas características en el lenguaje Java, que actualmente se están trabajando en los proyectos de Valhalla, Panamá y Loom. Expandir un idioma no es una tarea fácil, especialmente no es un idioma en el que el énfasis esté en la compatibilidad con versiones anteriores; por lo tanto, para que su integración en Java se realice sin problemas, los arquitectos de lenguaje deben resolver los problemas fundamentales acumulados.
Ayer (8 de enero), Brian Goetz, trabajando para Oracle como Arquitecto de Lenguaje Java, publicó una
carta "¡Necesitamos más palabras clave, Capitán!" Para Project Amber
. en el que propuso una forma de resolver el problema de agregar nuevas palabras clave al idioma. Como resultado, las palabras clave pueden aparecer en el idioma, como
no nulo ,
no final ,
finalmente final y
este retorno (una lista completa lo está esperando debajo del recorte al final de la publicación).
Como en el pasado este problema surgía en el idioma con poca frecuencia, por lo general no pensaban mucho en ello y "trataban de salirse del cuello lo más rápido posible"; Debido a las deficiencias de los enfoques existentes en el futuro, su aplicación será problemática y, en este sentido, se decidió trabajar por adelantado. Solución propuesta: intente expandir el conjunto de formas léxicas que se pueden usar como palabras clave: permita palabras clave separadas por un guión, que utilizará una (o más) palabras clave existentes o un identificador reservado.
Nota importante: Brown señala que las nuevas palabras clave se proporcionan únicamente como un ejemplo ilustrativo y que no debe centrarse en ellas. Sin embargo, es obvio que tenemos ante nosotros una demostración bien pensada de cómo la sintaxis del lenguaje puede cambiar en el futuro: en la carta, el autor menciona que esta idea ayudará a agregar muchas construcciones de lenguaje que faltan a Java.
Métodos "antiguos"
Como saben, hoy en el lenguaje Java hay 50 palabras clave (
palabras clave ), que están prohibidas de usar como identificadores de variables. Se proporciona una lista completa
en la especificación del lenguaje JLS en la cláusula 3.9 . Esta lista no ha cambiado mucho desde la primera versión del lenguaje: solo
se agregó la
afirmación en la versión 4,
enumeración en 5 y
_ en 9. Además de ellos, también hay "identificadores reservados" -
verdadero ,
falso y
nulo - que se comportan de manera similar a las palabras clave camino.
Cuando los desarrolladores necesitan agregar una nueva palabra clave al idioma, tienen que recurrir a uno de los siguientes métodos.
- Transferencia forzada de propiedad: tomamos las palabras que antes eran identificadores y las convertimos en palabras clave (por ejemplo, afirmar ).
- Eliminación: una palabra clave existente comienza a usarse de una manera que nunca fue pensada (un ejemplo es el uso de valores predeterminados para anotaciones o métodos predeterminados).
- No lo haga: encuentre una manera de usar la sintaxis que no requiera una nueva palabra clave, por ejemplo, use la interfaz para anotaciones en lugar de una anotación , o abandone completamente la función.
- Creación de visibilidad: cree la ilusión de palabras clave sensibles al contexto utilizando logros lingüísticos heroicos ( palabras clave restringidas, nombres de tipos reservados ).
En principio, cualquiera de estos métodos generalmente se puede aplicar, pero cada uno de ellos tiene sus inconvenientes, y para una extensión seria a gran escala del lenguaje, estos métodos por sí solos no son suficientes: para futuras innovaciones, será necesario eliminar la incapacidad de extender completamente la sintaxis del lenguaje.
Agregar nuevas palabras clave
Existen los siguientes argumentos en contra de "solo" tomar y agregar nuevas palabras.
- Cuanto más conveniente y popular sea la palabra clave seleccionada, más a menudo aparecerá en el código fuente de los programas, lo que agregará incompatibilidad al lenguaje (por ejemplo, cuando la palabra aserción apareció en Java SE 1.4, todos los marcos de prueba dejaron de funcionar).
- El costo de eliminar dicha incompatibilidad del código por parte del desarrollador variará mucho de pequeño (renombrando una variable local) a fatal (cuando el método de interfaz o tipo público se invalida).
- Las palabras que los desarrolladores de lenguaje tienen más probabilidades de usar son identificadores populares (por ejemplo, valor , var o método );
- Si elige palabras que rara vez se usan en el código fuente y con las que habrá menos colisiones, tendrá que usar construcciones como generalmente_but_not_always_final , que en el lenguaje naturalmente sería deseable evitar.
- Si, sin embargo, recurre a elegir palabras raramente utilizadas, entonces usar este método con demasiada frecuencia no funcionará: romper la compatibilidad no es bueno y no hay tantas combinaciones más exitosas.
Reutilizando palabras clave "antiguas"
Sobre "solo" continuar viviendo con esas palabras, hay consideraciones.
- Los precedentes de reutilizar palabras clave en diferentes contextos se encuentran en muchos lenguajes de programación (un ejemplo de Java es el uso de ( (ab) use ) final para las designaciones "no mutable", "no redefinido" y "no extensible").
- Algunas veces este enfoque tiene sentido y viene solo, pero generalmente no es una prioridad.
- Con el tiempo, el conjunto de requisitos para un conjunto de palabras clave se expande, y puede llegar a un punto divertido: nadie quiere usar null final en su código.
- Si esto último le pareció una exageración, tenga en cuenta que, mientras trabajaba en JEP 325, sugirieron seriamente usar la nueva construcción del interruptor para describir el interruptor con una semántica diferente: si continúa en la misma línea, después de diez años podemos alcanzar Nuevo interruptor nuevo .
¿Cómo vivir sin nuevas palabras clave? Es posible dejar de participar por completo en la evolución del lenguaje, como algunos han sugerido. Pero esto no es serio y no encaja con la opinión del resto, ya que existe un gran interés en las nuevas características del lenguaje por parte de los desarrolladores.
Palabras clave contextuales
Las palabras clave contextuales que se utilizan para proporcionar un significado específico en el código, pero que no son palabras reservadas (
utilizadas en C # ) a primera vista, parecen ser la misma "varita mágica", pero aquí Brian expone su propia opinión sobre su uso, basado en la práctica ( por ejemplo, implementaciones
var en Java 10, que no es una palabra clave, sino un
nombre de tipo reservado ). A cambio de la ilusión de agregar nuevas palabras clave sin tener que "romper" los programas existentes, obtenemos una mayor complejidad y distorsión en el lenguaje.
Las palabras clave contextuales son difíciles para escritores de especificaciones, compiladores e IDE. En el caso de uno o dos casos especiales, esto no causa problemas, pero cuando comienzan a usarse en todas partes, se traduce en un costo mucho mayor de soportar el código o la cola de los errores.
Se podría descartar esto: dicen que no es un problema de los usuarios del lenguaje, sino de sus creadores y de quienes escriben compiladores e IDE. Pero en realidad, todos sufren. Para el IDE, esto puede ser un problema importante: se necesitará más información para adivinar lo que el desarrollador está ingresando: una palabra clave contextual o identificador. Como resultado, los usuarios experimentan un deterioro en el trabajo de resaltado de sintaxis, autocompletado y capacidades de refactorización.
Puede usar esta herramienta, pero hágalo con precaución.
Distorsión de la lengua
Parece que con los problemas que causan estos enfoques (sintaxis torpe, complicación innecesaria de la vida y errores), en principio, podríamos soportarlo. Pero hay otro problema que no es el más obvio: los matices del uso de palabras clave conducen al hecho de que el diseño del lenguaje en sí está distorsionado.
Para los desarrolladores de Java, escribir una
interfaz en lugar de una
anotación es común hoy en día, pero todos estarán de acuerdo en que usar el término amigable
anotación en lugar de una combinación de @ y la palabra clave "antigua" sería mucho más lógico.
Otro ejemplo: el conjunto de modificadores disponibles (público, privado, estático, final, etc.) no se puede llamar completo; no podemos decir nada que
no sea final o
no estático . A su vez, esto significa que no puede crear entidades en las que las variables o clases sean
finales por defecto, o los miembros sean
estáticos por defecto, ya que no hay forma de indicar que nos gustaría abandonar este modificador.
Este problema no es tan obvio para aquellos que usan el lenguaje, pero los autores del lenguaje en sí, debido a su deseo de desarrollarlo aún más, lo enfrentan constantemente, y todos tenemos que pagar por tales decisiones (cuando explícitamente, implícitamente).
La conclusión de todo lo anterior se sugiere a sí misma: necesitamos otra fuente de palabras clave.
Solución propuesta
En las capacidades experimentales del lenguaje, se usa una sintaxis para pre-designar nuevas palabras clave, en las cuales las nuevas palabras clave están precedidas por dos guiones bajos (por ejemplo, en el prototipo
Proyecto Valhalla es
__ByValue ). La razón de esta decisión es comprensible: debe señalar que se trata de un reemplazo temporal, por lo que en el futuro tendrá que tomar una decisión sobre la sintaxis final, y al mismo tiempo puede evitar fácilmente conflictos con el código existente. Se podría sugerir el uso de un formato similar para nuevas palabras clave, comenzando con uno o dos guiones bajos, pero esta solución no se puede llamar hermosa, porque en este caso obtendremos confusión de palabras clave comunes y nuevas.
Por lo tanto, se propone utilizar palabras clave construidas con un guión, que utilizará una o más palabras clave "antiguas" o identificadores reservados.
A diferencia de
las palabras clave restringidas , este enfoque creará muchos menos problemas para el análisis, ya que (en adelante, un ejemplo)
no nulo no se puede confundir con una expresión de resta, y un lexer siempre puede determinar si
ab es tres tokens o uno. Gracias a esto, se nos abren nuevas oportunidades para crear palabras clave que tienen menos probabilidades de entrar en conflicto con el código fuente existente o entre sí. Además de eso, es mucho más probable que tengan nombres significativos, ya que gran parte de lo que los creadores del lenguaje quieren agregar a Java se basa en construcciones de lenguaje existentes en él, por ejemplo,
no nulo .
Como ejemplos de nuevas palabras clave, se dan candidatos probables para el lugar de nuevas palabras clave (recuerdo que según el autor, en este momento esta lista es puramente ilustrativa):
-
no nulo ;
-
no final ;
-
package-private (modificador del nivel de acceso a los miembros de la clase por defecto, que actualmente no se indica de ninguna manera);
-
lectura pública (
lectura pública, grabación privada);
-
anulado ;
-
type-static (el concepto necesario para
Valhalla ; denota static en relación con la especialización específica de la clase, y no la clase en sí misma);
-
valor por defecto ;
-
event-final (lo que se supone que debe hacerse ahora usando la anotación
estable ),
-
semifinal (como alternativa al
sellado );
-
interruptor exhaustivo ;
-
enum-class ,
annotation-class ,
record-class (los autores del lenguaje podrían usar estas palabras clave como una alternativa a
enum e
interface , si tuvieran esa oportunidad);
-
this-class (para describir el literal de la clase para la clase actual);
-
this-return (a menudo se le pide que agregue una forma de marcar el creador de métodos / creador de métodos como devolviendo su destinatario).
Seguramente hay otras variantes de esquemas léxicos según los cuales sería posible componer palabras clave para que se superpongan mínimamente con las ya escritas por el código fuente. El guión propuesto es lo suficientemente legible tanto para automóviles como para humanos.
Se entiende que este enfoque de ninguna manera excluye la posibilidad de usarlo junto con los que se usaron antes, sino que se usará junto con ellos.