peliculas - groovy traduccion

Groovy: ¿cuál es el propósito de "def" en "def x=0"?

Question

En el siguiente fragmento de código (tomado de la página de Groovy Semantics Manual ), ¿por qué prefijar la asignación con la palabra clave def ?

def x = 0
def y = 5

while ( y-- > 0 ) {
    println "" + x + " " + y
    x++
}

assert x == 5

La palabra clave def puede eliminarse y este fragmento produciría los mismos resultados. Entonces, ¿cuál es el efecto de la palabra clave def ?

Answer 1

En lo que se refiere a este único guión, no hay diferencia práctica.

Sin embargo, las variables definidas con la palabra clave "def" se tratan como variables locales, es decir, locales para este script. Las variables sin la "def" delante de ellas se almacenan en una llamada unión al primer uso. Puede pensar en el enlace como un área de almacenamiento general para variables y cierres que deben estar disponibles "entre" scripts.

Entonces, si tiene dos scripts y los ejecuta con el mismo GroovyShell, el segundo script podrá obtener todas las variables que se establecieron en el primer script sin una "def".

Answer 2

En realidad, no creo que se comporte de la misma manera ...

las variables en Groovy aún requieren una declaración, pero no la declaración TYPED, ya que el lado derecho generalmente contiene suficiente información para que Groovy escriba la variable.

Cuando trato de usar una variable que no he declarado con def o un tipo, aparece el error "No such property", ya que supone que estoy usando un miembro de la clase que contiene el código.

Answer 3

Es azúcar sintáctica para scripts básicos. Omitir la palabra clave "def" coloca la variable en los enlaces del guión actual y groovy la trata (en su mayoría) como una variable con ámbito global:

x = 1
assert x == 1
assert this.binding.getVariable("x") == 1

El uso de la palabra clave def en su lugar no coloca la variable en los enlaces de scripts:

def y = 2

assert y == 2

try {
    this.binding.getVariable("y") 
} catch (groovy.lang.MissingPropertyException e) {
    println "error caught"
} 

Imprime: "error capturado"

Usar la palabra clave def en programas más grandes es importante ya que ayuda a definir el alcance en el que se puede encontrar la variable y puede ayudar a preservar la encapsulación.

Si define un método en su secuencia de comandos, no tendrá acceso a las variables que se crean con "def" en el cuerpo de la secuencia de comandos principal, ya que no están dentro del alcance:

 x = 1
 def y = 2


public bar() {
    assert x == 1

    try {
        assert y == 2
    } catch (groovy.lang.MissingPropertyException e) {
        println "error caught"
    }
}

bar()

imprime "error capturado"

La variable "y" no está dentro del alcance dentro de la función. "x" está en el alcance ya que groovy verificará los enlaces del script actual para la variable. Como dije antes, esto es simplemente azúcar sintáctica para hacer que las secuencias de comandos rápidas y sucias sean más rápidas de escribir (a menudo una línea).

Una buena práctica en los scripts más grandes es usar siempre la palabra clave "def" para que no se encuentre con problemas de alcance extraños o interfiera con las variables que no pretende.

Answer 4

Lo más importante es que realmente no todos quieren crear una variable por accidente. Está bastante bien en los scripts tener variables creadas en una tarea, pero en el código de producción es uno de los mayores males que puedes encontrar. No consideraré ningún lenguaje que permita que esta construcción sea utilizable en el código de producción.

Me entrevisté en más de un lugar que usaba Visual Basic donde preguntaban "¿Cuál es la primera línea en cualquier archivo VB?" Y si no respondía "OPTION EXPLICIT", la entrevista se detenía allí mismo. (OPTION EXPLICIT no permite la creación de variables mediante la asignación en VB y fuerza un "dim" explícito)

Aquí hay un ejemplo de por qué es malo. Esto se ejecutará (sin fallar la afirmación) si copia el siguiente código y lo pega en una secuencia de comandos groovy:

bill = 7
bi1l = bill + 3
assert bill == 7

También elimina parte de la capacidad del compilador para ayudarte a refactorizar. Por ejemplo, si cambia el nombre del lugar donde usa la variable por primera vez, ¿cómo sabe el compilador si el segundo uso (una asignación) ahora es un error y no una nueva variable?

Mierda como esta es demasiado peligroso. Incluso si solo te mordía una vez en la vida, aún te costaría más tiempo que declarar explícitamente las variables miles de veces a lo largo de tu carrera. También se vuelve claro para la vista dónde se está retrasando, no tienes que adivinar.

En las secuencias de comandos, está bastante bien porque el alcance del guión es limitado y no se reutilizan y mantienen tanto como se reescriben, pero un lenguaje que permite la creación en la asignación simplemente no está listo para la producción.

Answer 5

Según esta page , def es un reemplazo para un nombre de tipo y simplemente se puede considerar como un alias para Object (es decir, que significa que no te importa el tipo).

Answer 6

La respuesta de Ted es excelente para los guiones; La respuesta de Ben es estándar para las clases.

Como dice Ben, piense en ello como "Objeto", pero es mucho más genial ya que no lo obliga a utilizar los métodos de Objeto. Esto tiene claras implicaciones con respecto a las importaciones.

Por ejemplo, en este fragmento tengo que importar FileChannel

// Groovy imports java.io.* and java.util.* automatically
// but not java.nio.*

import java.nio.channels.*

class Foo {
    public void bar() {
        FileChannel channel = new FileInputStream(''Test.groovy'').getChannel()
        println channel.toString()
    }
}

new Foo().bar()

Por ejemplo, aquí puedo simplemente ''aletear'' siempre que todo esté en la ruta de clases

// Groovy imports java.io.* and java.util.* automatically
// but not java.nio.*
class Foo {
    public void bar() {
        def channel = new FileInputStream(''Test.groovy'').getChannel()
        println channel.toString()
    }
}

new Foo().bar()