(Архив) Matreshka.js — MK.Array

[Starfall]

«Методы оригинального Array [...] в MK.Array возвращают себя.»

Представьте: сидит программист в офисе, пишет код. Вдруг рядом его коллега восклицает: «Что за ***?!» Наш герой оборачивается, спрашивает: «Зачем ты такое говоришь?» А тот ему отвечает: «Понимаешь, я привык, что pop() возвращает удаленный элемент. А тут вместо элемента оказался массив. 15 минут убил на отладку; оказалось, что это особенность фреймворка...»

Все-таки, в программном интерфейсе тоже есть «юзабилити».

[Finom]

Это прописано в документации.

[Starfall]

Согласен. Коллега из моего примера тоже ее читал и… не запомнил. Или не заметил.

parseInt(«08») === 0 // Это тоже прописано в документации, и все равно разработчики спотыкаются (когда парсят пользовательский ввод, например)

[Slavenin999]

parseInt(«08») === 0 // Это тоже прописано в документации, и все равно разработчики спотыкаются (когда парсят пользовательский ввод, например)

эм… что-то здесь не так… консоль говорит, что
parseInt('08') === 8 true; parseInt('08') === 0 false

[Starfall]

На самом деле, так было до 5-й редакции ECMAScript. В новых браузерах эту «фичу» уже убрали. Однако, в IE8 такое поведение наблюдается до сих пор.

stackoverflow.com/questions/850341/how-do-i-work-around-javascripts-parseint-octal-behavior

[Slavenin999]

ие не пользуюсь. а вот последние версии оперы, хрома и фф стабильно выдают:

parseInt('08') === 8 true; parseInt('08') === 0 false

[winbackgo]

Я думал про pop и shift это — опечатка. Имхо так не должно быть.

[Finom]

Спасибо, я подумаю. Серьезно.

[justboris]

Нативные pop и shift возвращают убираемый элемент потому, что основной сценарий их применения — «достать и использовать».
Ваша версия pop и shift удаляет крайние элементы безвозвратно, не представляю в каких случаях это может пригодиться

[Finom]

Я предполагал, что программист компенсирует это тем, что предварительно достанет нужный элемент, а, затем, применит метод. Возвращаемое значение удаляется небезвозвратно, оно попадает в объект соответствующего события (свойство returns). Но я с вами соглашусь и, возможно, внесу изменения.

[Zibx]

А оно умеет работать медленнее нативных массивов? А то устал уже от слишком отзывчивых пользовательских интерфейсов.

[Finom]

Любая работа с коллекциями (например, в том же бекбоне) требует больше вычислительных ресурсов, чем работа с чистыми данными. На мой взгляд, код достаточно оптимален, так как методы не переписаны заново. А когда умрет ИЕ8, скорость MK.Array еще больше увеличится.

[Zibx]

Это именно то, что меня пугает. Я не про матрёшку, а про бэкбоун в том числе. Производительность современных мобильных устройств в плане js близка как раз к ie8, а мы возьмём и сделаем модель, которая будет на каждый чих файрить эвенты, валидироваться, добавлять айдишки к данным, тем самым давая возможность быстро найти глобально эту запись по ид. Вместо всего этого счастья я предпочитаю использовать массивы и объекты как хэш-индексы, имеюшие сложность поиска log2. У нас продакшен код с кучей паттернов и бэкбоном с плагинами, которые оттестированы и стабильны тормозит на и7 по этой причине (сингл пейдж веб аппликейшен) и заводят баг «оптимизировать», а код на нативных структурах летает, но поддерживать его могу только я. Причём понятны оба подхода. Бэкбоун позволяет быстро написать рабочее решение, которое загнётся под нашими объёмами данных. Нативно приходится писать велосипеды и использовать свой код, но летает. Накипело, простите :). Опять же, ничего против матрёшки не имею. Добавьте мультидайменшенал индексы. Хотя напишу лучше личным сообщением.

[termi]

Вот вам идея: не замедлять все браузеры, копируя туда-сюда массивы, а проверять, что текущий браузер — это IE8, а точнее, что браузер не умеет полноценно JavaScript 1.6. Это проверяется достаточно легко:

var supportJS1_6 = false;
try {
    supportJS1_6 = window.isNaN.apply(window, {length: 1, 0: void 0})
}
catch(e) { }

И для IE8 написать отдельную функцию createArrayMethod. Это же позволит вам в будущем выпилить (или вынести) поддержку IE8

[Finom]

Если так сделать, то итераторы будут работать по-разному в осле и браузерах. Хотя, в целом, идея здравая. Кроме итерирующих методов есть и другие.