Después de ver this link, quiero probar Groovy ++, pero tengo una preocupación;¿Todo el código de Groovy es válido con Groovy ++?
¿Toda la sintaxis de Groovy es válida en Groovy ++?
Por ejemplo, yo puedo hacer esto en Groovy:
def list = [1,2]
es el código anterior válido en Groovy ++?
El objetivo (creo) es conseguirlo para soportar tanto código Groovy como sea posible.
Creo que hay actualmente unas pocas áreas que no están funcionando incluyendo:
pero siempre se puede evitar estos problemas, o no marcan la clase que los necesita como @Typed
Debe ser puesto en Groovy ++ puede:
Referencia: http://code.google.com/p/groovypptest/wiki/Welcome
Hay una lista de diferencias con ejemplos de código en http://groovy.dzone.com/articles/groovycomparetogroovy-part-1
Algunas de las diferencias:
a) no se preocupe. el rendimiento no es un problema ni groovy ni Groovy ++. En ambos idiomas, principalmente escribes pegamento-lógica. El código que conecta las diversas bibliotecas de Java. Y esas bibliotecas están escritas en Java, por lo que funcionan a toda velocidad.
A veces notas que has escrito una gran cantidad de código en groovy y te gustaría añadir algo más de velocidad. No hay problema. Groovy es ideal para crear prototipos de tu algoritmo. Como Groovy tiene una sintaxis similar a Java y hace uso de todas esas bibliotecas java, no hay problema para convertir tu prototipo en una biblioteca java que funcione a toda velocidad (sí, tienes que codificarlo manualmente, pero esto significa que eres solo 'tiene que eliminar todos esos accesos directos de su código Groovy para convertirlo en java).
b) por lo que entiendo groovy ++, funciona a través de anotaciones. Solo si anota el código, se lo reconocerá como código Groovy ++. Entonces debería funcionar Pero como se puede ver en todas estas respuestas, no mucha gente usa Groovy ++ en este momento, ya que el rendimiento no es un problema (ver a :-).
BTW: Creo que el tenedor maravilloso ++ pronto se fusionará en el tronco maravilloso estándar ...
¿Realmente cree que el rendimiento no es un problema? –
Sí. Tal vez es porque lo uso para las cosas correctas. No me gustaría codificar un raytracer en groovy, pero podría imaginarme escribir el prototipo en groovy o en alguna parte de él. Pero cuando escribo una aplicación de Grails (para eso uso groovy principalmente), el rendimiento realmente no es problema. – rdmueller
@ralf. Todavía hay conversaciones de que Grails es muy lento, y no pudimos controlar todas y cada una de las cosas en Grails. Significa Grails hacer cosas más rápido, pero no podemos ir en profundidad? ¡Es verdad! – testing31
Groovy ++ introdujo @Typed anotación (TypePolicy.MIXED), lo que es totalmente compatible con Groovy.
Al usar @Typed (TypePolicy.DYNAMIC) o al no usar @Typed, perderá todas las ventajas de Groovy ++.
MIXED TypePolicy optimiza lugares estáticos si es posible.
@Typed (TypePolicy.MIXED) hace la vida de un desarrollador que quiere optimizar el código usando groovy ++ ciertamente más fácil. Sin embargo, no es totalmente compatible con el código Groovy.
todavía hay cuestiones de compatibilidad incluso con maravilloso código ++ utilizando @Typed (TypePolicy.MIXED)
por ejemplo, maravilloso tipo de estilo de fundición (usando la palabra clave "como")
String foo = myUntypedFoo as String
necesita ser cambiado a
String foo = (String)myUntypedFoo
también variables declaradas fuera de los cierres no se puede utilizar directamente en estos cierres:
@Typed(TypePolicy.MIXED)
def countMatches(List<String> bahList, String pattern){
int counter = 0
bahList.each{ String bah ->
if (bah==pattern) counter++
}
}
debe cambiarse al estilo de Java (se rebate el propósito de Groovy ++) o se deben usar objetos de referencia.
groovy ++ es muy útil para mejorar el rendimiento groovy/grails, pero ciertamente no es una manera fácil y no estoy seguro, si debería usar java.
Si marca todo el paquete como @Typed, puede optar por excluir marcando una clase o método individual como @Typed (TypePolicy.DYNAMIC) –