Ruby 2.7: 파이핑 사업자

Ruby 2.7에 파이프 조작부호(|>가 추가되었지만 많은 Ruby 개발자들이 예상한 것처럼 그렇게 되지는 않았다.
The merge can be found here .
업데이트:
건설성과 문명의 피드백(MINASWAN)을 유지하고 그가 언급한LISP-1/LISP-2 namespacing 문제를 주목해 주십시오. 왜냐하면 이것은 진정한 불로장생의 약관을 실현하는 진정한 문제이기 때문입니다.
Ruby Bugtracker에서 논의 중

그것의 작용
파이핑 연산자는 소스 코드에서 점 링크의 별칭입니다.

# This code equals to the next code.

foo()
  |> bar 1, 2
  |> display

foo()
  .bar(1, 2)
  .display

...테스트 코드에 따라 다음을 수행합니다.

def test_pipeline_operator
  assert_valid_syntax('x |> y')
  x = nil
  assert_equal("121", eval('x = 12 |> pow(2) |> to_s(11)'))
  assert_equal(12, x)
end

본고에서 말한 바와 같이 이것은 파이프 조작부호의 현재 실현이다. 예를 들어Ruby bug tracker에서 말한 바와 같다.
Chris Salzbergmentioned는 이 기사에서 우선 순위가 점 연산자보다 낮을 수 있다고 지적했다.

The operator has lower precedence than ., so you can do this:

a .. b |> each do
end

With ., because of its higher precedence, you'd have to do use braces:

(a..b).each do
end

...그는 책에서 다음과 같이 썼다.

The bigger point IMHO though is that major controversial decisions are
made based on this kind of very brief, mostly closed discussion.

나는 그와 이 변화를 토론하는 몇몇 사람들의 관점에 동의하는 경향이 있으며, 찬성과 반대를 포함한 나의 이유를 아래에서 논술할 것이다.

찬성표
찬성하는 관점에서 나는 몇 가지를 보았다.

루비는 이미 여러 블록의 문법이 있다
One of the points가 제기한 문제는 루비가 블록을 만드는 데 사용할 문법이 이미 여러 개 있다는 것이다. 예를 들어 do ... end와 { ... }이다.
냉각 라인은 여러 줄 메서드의 한 방식으로 간주되며 이를 더욱 명확하게 나타냅니다.

# Original
foo.bar.baz

# Current
foo
  .bar
  .baz

# Alternate Current:
foo.
  bar.
  baz

# Pipelined:
foo
|> bar
|> baz

대위
나의 반대 의견은 루비 블록은 이미 새로운 개발자들을 곤혹스럽게 하고, 루비를 공부할 때 자주 논쟁을 일으킨다는 것이다.
명확한 구분 요소가 없는 새로운 언어 구조를 추가하는 것은 이런 상황을 심화시켜 언어를 더욱 배우기 어렵게 할 뿐이다.

우선하다
다른 점raised은 파이프 조작부호의 우선순위가 .보다 낮아서 위에서 언급한 무변수 프로그래밍을 허용한다.

# Current
(a..b).each do
end

# Pipelined
a .. b |> each do
end

대위
우리도 영어 연산자and와 or보다 우선하는 논점이 있는데, 혼동을 일으킬 수 있기 때문에 사람들은 이 두 연산자가 이 언어에서 흔히 볼 수 없다고 보편적으로 생각한다.
위에서 언급한 같은 임무의 여러 문법이 서로 다른 선례가 있는 것처럼 새로운 프로그래머들도 곤혹스러울 것이다.

주요 반대 의견
최근에 논란이 되는 기능들이 등장했다. 예를 들어 정확한 문법에 대해서도 논란이 있었지만 몇 가지 토론은 이 기능을 지지했다. 왜냐하면 언어에 뚜렷한 새로운 내용을 추가했기 때문이다.
이런 상황에서 나는 상황이 결코 그렇지 않다고 생각한다.새로운 파이프 조작부호는 . 의 별명처럼 느껴지는데, 이것은 문법상의 당분이며, 본래 이 언어에 더욱 적합할 수 있었다.
찬성의 주요 관점은 우선순위 계산의 차이와 관련이 있는데, 이 문제는 과거 비교적 새로운 루비 프로그래머들 사이에서 큰 혼란을 일으켰고, 지금까지도 계속되고 있다.
한 언어에 새로운 기호를 도입하면 이런 언어로 일을 하기 위해 새로운, 더욱 표현력 있는 방식을 늘려야 한다.나는 이것이 이 목표를 실현할 수 있을 것이라고 믿지 않는다.

이 가능하다, ~할 수 있다,...
이와 반대로 다른 언어의 파이프는 코드의 강력한 표현 기능이다.나는 당신에게 그 중의 일부 실현을 보여주고 그것들의 장점을 스스로 판단하도록 하고 싶습니다.

Javascript에서
TC39에는 discussed a pipeline operator가 있으며 현재 면밀히 평가 중입니다.자바스크립트는 루비와 매우 비슷하기 때문에 이 두 언어 사이에는 많은 생각이 있을 뿐만 아니라 더 많은 생각이 있을 수도 있다.
예를 들면 다음과 같습니다.

const double = (n) => n * 2;
const increment = (n) => n + 1;

// without pipeline operator
double(increment(double(double(5)))); // 42

// with pipeline operator
5 |> double |> double |> increment |> double; // 42

파이프 조작부호는 왼쪽의 출력을 오른쪽의 입력에 제공하는 데 사용됩니다.이것은 함수의 유일한 매개 변수임을 명확하게 요구한다. 두 언어의 카레 기교를 통해 이 매개 변수를 돌릴 수 있고 일부는 함수를 응용할 수 있다.

Ruby에서 Javascript 파이핑 적용
이는 then의 루비 약속과 매우 유사합니다.

double = -> n { n * 2 }
increment = -> n { n + 1 }

double[increment[double[double[5]]]]
# => 42

5.then(&double).then(&double).then(&increment).then(&double)

파이프 조작부호가 then의 별명이라면 to_proc/&와 방법이 호출된 것을 합리적으로 추정할 수 있다. 그러면 자바스크립트와 완전히 같다.

5 |> double |> double |> increment |> double
# => 42

이렇게 하면 다음과 같은 몇 가지 주요 항목이 구현됩니다.

명시적 블록 레이블을 사용하기 위한 필요 없음&

코드

의 변형을 간소화했다

지능적인 처리 방법 및 프로세스

처리 방법 및 프로세스를 통해 이러한 코드의 출력은 변경되지 않습니다.

def double(n)
  n * 2
end

increment = -> n { n + 1 }

5 |> double |> double |> increment |> double
# => 42

나는 이것이 더욱 진실한 루비 실현이라고 믿는다. 루비는 표현력이 강하고 우아하며, 더욱 간단한 문법이 더욱 복잡한 생각을 틈새 없이 담을 수 있도록 허락한다.
이것은 연산자가 있는 Duck 유형의 사상을 사용하여 이 두 가지 유형의 행위가 동일해야 한다는 것을 나타내고 매우 강한 문법을 실현해야 한다는 것을 나타낸다.

Ocaml 및 F에서
Ocaml과 F#의example는 매우 비슷해 보이기 때문에 우리는 F#변체에 중점을 두고 이 점과 구도 간의 차이를 강조할 것이다(나는 여기서 소개하지 않지만 읽을 만하다).

let (|>) x f = f x

마지막 매개변수를 함수에 파이핑하여 작업합니다.

let doSomething x y z = x+y+z
doSomething 1 2 3       // all parameters after function
3 |> doSomething 1 2    // last parameter piped in

F#에 익숙하지는 않지만 Javascript 예제에서 언급한 기능들을 잘 구현한 것 같습니다.

F# 파이프는 Ruby에 적용
이것은 함수에 매개 변수를 적용한 다음 마지막 매개 변수가 호출될 때까지 기다리는 흥미로운 커리 방법을 도입했다.Ruby 버전 then:

adds = -> a, b { a + b }.curry

adds[2, 3]
# => 5

adds[2]
# => #<Proc:0x00007fe8ab6996a0 (lambda)>
adds[2][3]
# => 5

나는 자동 카레가 루비와 잘 어울릴 것이라고 생각하지 않지만, 그것은 파이프 조작부호에 재미있는 기능을 추가할 것이다.

adds = -> a, b { a + b }.curry

def double(n)
  n * 2
end

increment = -> n { n + 1 }

5 |> adds[2] |> double |> increment
# => 15

불로장생약
Elixir works much the same wayJavascript로 구현되며'소프트 카레'함수를 제외하고 파이프에서 추가 입력을 기다릴 수 있습니다.
다시 한 번 말씀드리지만 저는 장생불로약에 대해 잘 몰라요. 여러분들이 바로잡아 주셨으면 좋겠어요.

"Elixir rocks" |> String.upcase() |> String.split()
["ELIXIR", "ROCKS"]

"elixir" |> String.ends_with?("ixir")
true

흥미로운 점은 Ruby가 겪을 수 있는 문제 중 하나인 괄호 주위의 문법이 명확하지 않다는 점이다.

iex> "elixir" |> String.ends_with? "ixir"
warning: parentheses are required when piping into a function call.
For example:

  foo 1 |> bar 2 |> baz 3

is ambiguous and should be written as

  foo(1) |> bar(2) |> baz(3)

true

그룹 월드
지금 놀라운 발견이 하나 있다. 나는 그것을 curry의 별명으로 즐겨 사용하지만...
...그것은 반드시 이 두 언어와 다른 언어의 상술한 사상의 결합이어야 한다.

5
|> double
|> increment
|> to_s(2)
|> reverse
|> to_i

이것은 우리로 하여금 현재의 실현을 다른 언어의 이미 정한 사상과 통일시키는 동시에 표현 능력을 크게 향상시켰다.만약 이러한 실현이 사용에 투입될 수 있다면, 나는 매우 흥분할 것이다. 왜냐하면 기능 세계에서 가장 좋은 것을 루비의 자연 대상과 결합시켜 새로운 것을 실현할 수 있기 때문이다.
나에게 이것이 바로 루비다. 세계 각지와 다양한 언어에서 온 아이디어를 통해 새로운 것을 실현했다.우리는 이 소설과 감동적인 작품을 결합시켜 우리 자신의 작품이 되도록 했다. 나는 파이프 운영자가 있어서 우리가 이 점을 실현할 수 있는 놀라운 기회가 있다고 믿는다.
나는 단지 현재의 실시가 이 잠재력을 완전히 실현시켰다고 믿지 않을 뿐이다. 이것은 나를 슬프게 한다.