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 должны реализовывать нулевую проверку. Это легко.

_.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??

В начале цепочки история может показаться немного другой на первый взгляд, но я утверждаю, что это то же самое и что мы должны оставить ее с нулевой проверкой. По крайней мере, должно быть так, что у программиста есть причина ожидать, что something будет похожим на изменяемый массив, поскольку в противном случае не было бы причин вызывать push :

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

Ожидание, что something является изменяемым массивом, может не оправдаться по целому ряду причин:

1. giveMeAMutableArraylike #$ по какой-то причине уравняли с null или undefined . Это сравнимо с первым примером цепочки посередине и может быть решено той же проверкой нуля.
2. Вызывающий абонент пытается заставить giveMeAMutableArraylike сделать то, чего он явно не может сделать, т. е. нарушить контракт. Это сравнимо со второй цепочкой посередине. Опять же, я думаю, что в этом случае можно выдать ошибку.
3. something — это голое значение вместо массива с одним элементом, т. е v вместо [v] . Это обычная ситуация во многих API JavaScript. Если контракт giveMeAMutableArraylike допускает это, очевидно, неправильно выдавать ошибку независимо от того, что такое v .

В последнем случае Underscore не может знать, разрешает ли giveMeAMutableArraylike одиночные голые элементы или нет, поэтому программист giveMeAMutableArraylike должен реализовать свой конкретный контракт. Нет ничего такого, что библиотека вроде Underscore могла бы сделать правильно для всех возможных контрактов:

| Текущее поведение | Обернуть одноэлементным массивом
---|---|---
Контракт позволяет голый один элемент | _Программист должен вмешаться_ | Подчеркивание делает правильные вещи автоматически
Контракт не позволяет оголять один элемент | Подчеркивание делает все правильно автоматически | _Программист должен вмешаться_

Кроме того, как вы решаете, следует ли обернуть значение? Некоторые контракты могут захотеть обернуть все, что не является Array , в то время как другие могут захотеть передать arguments и простые объекты как есть. Опять же, это то, что такая библиотека, как Underscore, не может угадать от имени пользователя.

Возможны и более экзотические ситуации, например контракт, который разрешает неизменяемые объекты, подобные массивам, такие как строки, и который сначала преобразует их в Array . Невозможно охватить все возможные варианты. По принципу наименьшего изменения просто нет убедительных аргументов в пользу поддержки некоторых контрактов за счет контрактов, которые уже поддерживались. Существует также веский аргумент в пользу минимизации реализации.

Поэтому я думаю, что правильным решением будет вставить только нулевую проверку и оставить все как есть. Это единственное изменение в поведении Underscore, которое кажется оправданным во всех мыслимых ситуациях, и оно также согласуется с поведением _.extend . Нулевая проверка все еще может считаться исправлением ошибки, в то время как выполнение чего-либо большего быстро превратит ее в произвольное критическое изменение.

@jashkenas , не могли бы вы пролить свет на это? Если вы согласны, я подготовлю пулл-реквест, реализующий проверку на нуль.

@jgonggrijp — Можете ли вы в одном-двух предложениях рассказать о поведении, которое вы хотите реализовать с помощью проверки нуля?

Это методы массива будут явно генерировать исключение при вызове нулевого значения? Или что они будут noop при вызове нулевого значения?

@jashkenas Да. Поведение, которое я бы реализовал, является неоперативным, следуя стилю функций массива подчеркивания:

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

Плюс тесты, конечно, и если эти тесты выявят необходимость, может быть еще и проверка на null, которая превращает метод в no-op перед этой строкой:

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

Звучит хорошо для меня!