Underscore: 배열이 아닌 값에 대한 배열 체인 메서드 오류

이것은 또 다른 문제를 야기합니다. 배열과 유사한 것을 배열로 캐스팅해야 합니까?

_('hello').first() // 'h'
_('hello').pop() // ?

이것은 여전히 ​​문제인 것 같습니다 - 1.8.3 t0 1.9.0에서 우리 버전을 범한 후에 발생했습니다.

편집: 1.9.1에서 수정된 것 같습니다. 그렇다면 이 문제를 계속 열어 두어야 합니까?

이 동작은 여전히 ​​1.10.2에 존재합니다.

둘 다 제자리에서 값 수정을 포함하기 때문에 내 옵션에서 약간 더 설득력 있는 대조:

Object.assign(undefined, {a: 1})  // error
_().extend({a: 1})  // undefined

Array.prototype.push.call(undefined, 1)  // error
_().push(1)  // error

나는 이것이 일관성이 없다는 데 어느 정도 동의합니다.

어떤 종류의 실제 상황에서 이것이 가장 많이 발생할 수 있으며 그러한 경우에 래핑된 객체에 대해 무엇을 기대할 수 있는지 고려해 볼 가치가 있습니다.

체인의 중간 에서 래핑된 개체는 예측 가능합니다. 예를 들어 아래 체인에서 push 에 전달되는 래핑된 개체는 Array 또는 undefined 입니다. 이러한 이유로 Array 래퍼 메서드는 null 검사를 구현해야 한다고 주장합니다. 이것은 쉬워요.

_.chain(something).map(f).push(x)  // hoping to push x to an array

예측된 래핑된 개체가 배열이 아닌 다른 것일 가능성이 더 높으면 틀림없이 프로그래머 오류일 수 있습니다. 나는 그 경우에 예외를 던지는 것에 신경 쓰지 않는다.

_.chain(something).map(f).join('').push(x)  // hoping to push x to a string??

체인의 시작 부분에서 이야기는 언뜻보기에는 약간 다르게 보일 수 있지만 동일하며 null 체크로 남겨 두어야한다고 주장합니다. 적어도 프로그래머는 something 가 가변 배열과 비슷할 것으로 예상할 수 있는 어떤 이유가 있어야 합니다. 그렇지 않으면 push 를 호출할 이유가 없기 때문입니다.

function giveMeAMutableArraylike(something) {
    _.chain(something).push(x)
}

something 가 가변 배열과 유사하다는 기대는 다양한 이유로 충족되지 않을 수 있습니다.

1. giveMeAMutableArraylike 는 어떤 이유로든 null 또는 undefined 로 호출되었습니다. 이것은 첫 번째 chain-in-the-middle 예제와 비슷하며 동일한 null 검사로 해결할 수 있습니다.
2. 호출자는 giveMeAMutableArraylike 가 분명히 할 수 없는 일, 즉 계약 위반을 하도록 하려고 합니다. 이것은 두 번째 chain-in-the-middle 예제와 비슷합니다. 이 경우에도 오류를 던지는 것은 괜찮다고 생각합니다.
3. something 는 단일 요소가 있는 배열 대신 순수한 값입니다. 즉, v [v] 입니다. 이것은 많은 JavaScript API에서 일반적인 상황입니다. giveMeAMutableArraylike 의 계약이 이를 허용한다면 v 가 무엇이든 상관없이 오류를 던지는 것은 분명히 잘못된 것입니다.

후자의 경우 Underscore는 giveMeAMutableArraylike 가 단일 베어 요소를 허용하는지 여부를 알 수 없으므로 giveMeAMutableArraylike 의 프로그래머가 특정 계약을 구현해야 합니다. Underscore와 같은 라이브러리가 가능한 모든 계약에 대해 올바른 작업을 수행할 수 있는 것은 없습니다.

| 현재 행동 | 단일 요소 배열로 래핑
---|---|---
계약은 베어 단일 요소를 허용합니다 | _프로그래머가 개입해야 합니다_ | 밑줄은 자동으로 올바른 작업을 수행합니다.
계약은 베어 단일 요소를 허용하지 않습니다 | 밑줄은 자동으로 올바른 작업을 수행합니다 | _프로그래머가 개입해야 합니다_

또한 값을 래핑해야 하는지 여부를 어떻게 결정합니까? 일부 계약은 Array 가 아닌 모든 것을 래핑하려고 할 수 있지만 다른 계약은 arguments 및 일반 개체를 있는 그대로 전달하기를 원할 수 있습니다. 다시 말하지만 이것은 Underscore와 같은 라이브러리가 사용자를 대신하여 추측할 수 없는 것입니다.

더 이국적인 상황도 생각할 수 있습니다. 예를 들어 문자열과 같은 변경할 수 없는 배열과 같은 객체를 허용하고 먼저 Array 로 변환하는 계약이 있습니다. 가능한 모든 변형을 포괄하는 것은 불가능합니다. 최소 변경 원칙에 따라 이미 지원된 계약을 희생시키면서 일부 계약을 지원하는 것에 대한 설득력 있는 주장이 없습니다. 구현을 가능한 한 최소화해야 하는 강력한 경우도 있습니다.

따라서 올바른 솔루션은 null 검사만 삽입하고 그대로 두는 것입니다. 이것은 생각할 수 있는 모든 상황에서 방어할 수 있는 것처럼 보이는 Underscore의 동작에 대한 유일한 변경이며 _.extend 의 동작과도 일치합니다. 널 검사는 여전히 버그 수정으로 간주될 수 있지만 그 이상을 수행하면 신속하게 임의의 주요 변경 사항으로 전환됩니다.

@jashkenas 이것에 대해 빛을 발할 수 있습니까? 동의하시면 null 체크를 구현하는 pull request를 준비하겠습니다.

@jgonggrijp — null 검사로 구현하려는 동작을 한두 문장으로 자세히 설명할 수 있습니까?

null 값에 대해 호출될 때 배열 메서드가 명시적으로 예외를 throw합니까? 아니면 nullish 값이 호출될 때 헛소리를 하지 않을까요?

@jashkenas 네. 내가 구현할 동작은 Underscore 배열 함수의 스타일을 따르는 no-op입니다.

https://github.com/jashkenas/underscore/blob/4cf715f593805ba8d7c5685cd06c82b3cd9b55ae/modules/index.js#L495

length 수표가 필요하지 않다는 점을 제외하고는

if (obj == null) return chainresult(this, obj);

이 두 줄 사이:

https://github.com/jashkenas/underscore/blob/4cf715f593805ba8d7c5685cd06c82b3cd9b55ae/modules/index.js#L1654 -L1655

플러스 테스트는 물론이고 이러한 테스트에서 필요성이 드러날 경우 이 줄 전에 메서드를 no-op으로 바꾸는 null 검사도 할 수 있습니다.

https://github.com/jashkenas/underscore/blob/4cf715f593805ba8d7c5685cd06c82b3cd9b55ae/modules/index.js#L1665

나에게 잘 들린다!