technology start learning java scala return

java - start - ¿Propósito de la declaración de "devolución" en Scala?



scala technology (4)

¿Hay alguna razón real para proporcionar la declaración de return en Scala? (aparte de ser más "amigable con Java")


Aquí hay un ejemplo

Este método tiene muchas declaraciones if-else para controlar el flujo, porque no hay retorno (de eso es lo que vine, puedes usar tu imaginación para extenderlo). Tomé esto de un ejemplo de la vida real y lo modifiqué para que fuera un código ficticio (de hecho, es más largo que esto):

Sin retorno:

def process(request: Request[RawBuffer]): Result = { if (condition1) { error() } else { val condition2 = doSomethingElse() if (!condition2) { error() } else { val reply = doAnotherThing() if (reply == null) { Logger.warn("Receipt is null. Send bad request") BadRequest("Coudln''t receive receipt") } else { reply.hede = initializeHede() if (reply.hede.isGood) { success() } else { error() } } } } }

Con devolución:

def process(request: Request[RawBuffer]): Result = { if (condition1) { return error() } val condition2 = doSomethingElse() if (!condition2) { return error() } val reply = doAnotherThing() if (reply == null) { Logger.warn("Receipt is null. Send bad request") return BadRequest("Coudln''t receive receipt") } reply.hede = initializeHede() if (reply.hede.isGood) return success() return error() }

Para mí, el segundo es más legible e incluso más manejable que el primero. La profundidad de la sangría (con código bien formateado) es profunda y profunda si no utiliza una declaración de retorno. Y no me gusta :)


Considero que el return es útil cuando se escribe código de estilo imperativo, que generalmente significa código de E / S. Si está haciendo código funcional puro, no necesita (ni debería usar) return . Pero con el código funcional puede necesitar holgazanería para obtener un rendimiento equivalente al código imperativo que puede "escapar antes" usando return .


Ignorando las funciones anidadas, siempre es posible reemplazar los cálculos de Scala con devoluciones con cálculos equivalentes sin devoluciones. Este resultado se remonta a los primeros días de la "programación estructurada", y se llama el teorema del programa estructurado , inteligentemente.

Con funciones anidadas, la situación cambia. Scala te permite colocar un "retorno" enterrado en el interior de una serie de funciones anidadas. Cuando se ejecuta la devolución, el control salta de todas las funciones anidadas, al método interno que lo contiene (suponiendo que el método todavía se está ejecutando, de lo contrario se lanza una excepción). Este tipo de desenrollado de la pila podría hacerse con excepciones, pero no se puede hacer mediante una reestructuración mecánica del cálculo (como es posible sin funciones anidadas).

La razón más común por la que realmente desea regresar desde el interior de una función anidada es salir de un bloque de control de recursos o de imperativo imperativo. (El cuerpo de un imperativo para la comprensión se traduce en una función anidada, aunque parezca una afirmación).

for(i<- 1 to bezillion; j <- i to bezillion+6){ if(expensiveCalculation(i, j)){ return otherExpensiveCalculation(i, j) } withExpensiveResource(urlForExpensiveResource){ resource => // do a bunch of stuff if(done) return //do a bunch of other stuff if(reallyDoneThisTime) return //final batch of stuff }


Se proporciona con el fin de acomodar aquellas circunstancias en las que es difícil o engorroso organizar todas las rutas de flujo de control para que converjan en el extremo léxico del método.

Si bien es cierto, como dice Dave Griffith, que puede eliminar cualquier uso de return , a menudo puede ser más ofuscante hacerlo que simplemente cortar la ejecución con un return manifiesto.

Tenga en cuenta también que el return devuelve métodos, no funciones (literales) que se pueden definir dentro de un método.