Scala의 선물은 정말로 기능적입니까?

Question

나는이 블로그 post을 읽고 있는데, Futures은 단지 부작용의 래퍼이므로 계산법이므로 "기능적"이라고 주장하지 않습니다. 예를 들어 RPC 호출, HTTP 요청 등을 포함합니다. 맞습니까?

def twoUsersFeed(a: UserHandle, b: UserHandle) 
       (implicit ec: ExecutionContext): Future[Html] = 
    for { 
    feedA <- usersFeed(a) 
    feedB <- usersFeed(b) 
    } yield feedA ++ feedB 

이

you lose the desired property: consistent results (the referential transparency). Also you lose the property of making as few requests as possible. It is difficult to use multi-valued requests and have composable code.

나는 그것을 얻을하지 않습니다 두려워 :

블로그 포스트는 다음 예제를 제공합니다. 이 경우 consistent result을 어떻게 잃게되는지 설명해 주시겠습니까?

Answer 1

블로그 게시물은 Future 자체와 그것이 일반적으로 사용되는 방식 인 IMO 사이에 적절한 구별을하지 못합니다. 순수 함수 코드라고 불리는 Future을 작성한 경우 순수 함수 코드를 Future으로 작성할 수 있습니다. 그러한 코드는 원격으로 합리적인 의미에서 투명하게 "기능적"이 될 것입니다.

사실 사실 Future은 부작용이있는 방법으로 을 사용하는 경우 부작용을 제한적으로 제어 할 수 있습니다.. Future을 포장하여 webClient.get으로 만들면 해당 Future을 생성하면 HTTP 호출이 전송됩니다. 그러나 사실은 Future에 관한 것이 아니며, 그 사실은 webClient.get에 관한 것입니다!

블로그 게시물에 진실이 있습니다. 예를 들어 계산을 통해 계산을 표현하는 것을 분리합니다. Free 모나드는 더 효율적이고 테스트 가능한 코드가 될 수 있습니다. 예 : "쿼리 언어"를 만들 수 있습니다. 여기서 "A와 B의 모든 상호 친구의 프로필 사진 가져 오기"와 같은 작업을 실제로 실행하지 않고 표현할 수 있습니다. 이렇게하면 논리가 올바른지 테스트하기가 더 쉬워집니다 (예 : 동일한 쿼리를 "실행할"수있는 테스트 구현을 만들기가 쉽거나 "쿼리 개체"를 직접 검사하는 것보다 쉽기 때문에). 블로그 게시물 제안하려고 시도하고 있습니다. 예를 들어 여러 요청을 결합하여 동일한 프로필을 가져옵니다. (이것은 단순한 함수 프로그래밍의 문제조차도 아니다 - 일부 OO 도서는 "명령 패턴"에 대한 아이디어를 가지고있다.) 문법은 for/yield과 같은 IME 함수 프로그래밍 도구로 훨씬 쉽게 작업 할 수있다. 반면에 실행중인 경우 즉시 HTTP 요청을 실행하고 코드 로직이 동일한 프로파일을 두 번 요청하면 동일한 프로파일을 두 번 가져 오는 것을 피할 수있는 방법이 없다는 것이 fetchProfile 메소드의 경우입니다.

하지만 실제로는 Future 그 자체가 아니며,이 블로그 게시물은 도움이되는 것보다 혼란 스럽습니다.