Цель заявления «вернуть» в Scala?

Question

Есть ли настоящая причина предоставления заявления return в Scala? (кроме того, что они более «совместимы с Java»)

Answer 1

Игнорирование вложенных функций всегда позволяет заменить вычисления Scala с помощью эквивалентных вычислений без возврата. Этот результат восходит к ранним дням «структурированного программирования» и назван structured program theorem, достаточно умно.

С вложенными функциями ситуация меняется. Scala позволяет размещать «возврат» в глубину внутри серии вложенных функций. Когда возврат выполняется, управление выпрыгивает из всех вложенных функций в самый внутренний содержащий метод, из которого он возвращается (при условии, что метод на самом деле все еще выполняется, в противном случае создается исключение). Такой тип разворачивания стека может быть выполнен с исключениями, но не может быть выполнен путем механической перестройки вычисления (как это возможно без вложенных функций).

Наиболее распространенная причина, по которой вы действительно хотите вернуться изнутри вложенной функции, состоит в том, чтобы выйти из императивного для понимания или управления ресурсами блока. (Тело императива-осмыслению переводится на вложенную функцию, даже если она выглядит так же, как утверждение.)

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 
} 

Answer 2

Он предоставляется для того, чтобы приспособить те обстоятельства, при которых сложно или громоздко организовать все пути потока управления, чтобы сходиться на лексическом конце метода.

Хотя, по словам Дэйва Гриффита, вы можете устранить любое использование return, часто это может быть более запутанным, чем просто сократить сокращение короткого замыкания return.

Помните, что return возвращает методы, а не функции (литералы), которые могут быть определены в рамках метода.

Answer 3

Я рассматриваю return как полезно при написании императивного кода типа, который обычно означает, что I/Вывода. Если вы используете чистый функциональный код, вам не нужно (и не следует использовать) return. Но с функциональным кодом вам может понадобиться лень, чтобы получить производительность, эквивалентную императивному коду, который может «ускользнуть» с нуля, используя return.

Answer 4

Вот пример

Этот метод имеет много если-иначе заявления для управления потоком, потому что нет возврата (то есть то, что я пришел с, вы можете использовать свое воображение, чтобы расширить его). Я взял это из реального примера жизни и изменить его, чтобы быть фиктивный код (на самом деле это больше, чем это):

без возврата:

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() 
      } 
      } 
     } 
     } 
    } 

С возвращением:

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() 
    } 

На мой взгляд, второй является более читаемым и даже управляемым, чем первый. Глубина углубления (с хорошо отформатированным кодом) идет глубоко и глубоко, если вы не используете оператор return. И мне это не нравится :)