Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+158
this.startAdLoading = function(callback) {
this.adCallback = callback;
Array.prototype.remove = function(from, to) {
var rest = this.slice((to || from) + 1 || this.length);
this.length = from < 0 ? this.length + from : from;
return this.push.apply(this, rest);
};
...
}Очень полезный метод добавили массивам. Все тот же источник.
Запостил: 
wvxvw,
12 Августа 2013
Follow us!
Ох, слона то я и не заметил. Это использование вышеприведенного метода.
загрузи рекламу и получи бонус-функцию в прототипе массива!
Прям как в лоттерее.
> что по мнению автора
Ну там как бы как раз единственное место, где нормально.
а || б => а если а == ложь иначе б. Т.е. если параметр to не передали, то использовать from.
Но такие выкрутасы явно не соответствуют уровню окружающего кода, предполагаю, что автор не смог правильно сформулировать запрос к гуглу и выловил какой-то результат, который сам не понял, а использовал, как получилось.
О, нашел источник вдохновения. Надо сказать, что на стопке-переборе варианты тоже не ахти, там предлагают восновном в цикле splice() вызывать.
Так и тянутся руки пропущенный пробел вставить:)
А как ещё? Я бы в зависимости от ожидаемого размера массива и количества вырезанных элементов тоже либо сплайсом резал бы по 1, либо делал отдельный массив из того, что должно остаться. Разве что цикл был бы один.
Ещё вариант придумывается с Array.filter(), но тут точно хреновая идея из-за колбэка на каждый элемент. А что ещё?
Да простит меня Тарас, ссылку не нашел.
Второй ещё надо проверить (лень сейчас :) ) будет ли он реально быстрее сплайса - обычно скриптовая реализация проигрывает нативным функциям, даже при чуть меньшей сложности.
В случае выше память выделяется гарантировано всего один раз.
сплайсом 1 мс + 408 Кб
копированием элементов справа (вашу реализацию взял) 45 мс + 3,6 Мб.
Мда... ну это только говорит о том, насколько сам по себе ж.скрипт херово реализован, т.как более правильный алгоритм не может работать достаточно хорошо по сравнению с говноалгоритмом только потому, что говноалгоритм использует вызовы штатных функций...
Вот потому и живут аномальные на первый взгляд вещи, типа тримов регулярками.
Ну вот кому нафиг нужен ~? Я просто ни разу не видел случая требовавшего применения. В то же время в практически любой программе на ж.скрипте нужно делать замены в строках. Почему бы не использовать что-то типа "строка" ~ /регулярка/? Было бы в 100 раз удобнее. Ксор? - тоже офигенно полезная функция, да и вообще, все они, особенно в виду того, что все числа - флоаты...
Все ту же криптографию можно сделать и обычной математикой, а особенно принимая во внимание тормозную сущность ж.скрипта / отстутсвие типов данных необходимых для криптографии - от того, что есть эти функции, что нету их - ничего не зависит.
Ага, нук запилите мне xor или not обычной математикой. Только чур без цикла. А то оно и так то лагает как говно, а побитовым циклом будет лагать минимум в 60 раз больше ;)
1. Никому не нужно.
2. Даже если нужно, то не из чего.
3. Даже если делать из того, что есть, то циклы в ксоре - будет самой меньшей проблемой. Всю длинную математику нужно будет далать на строках, от того, что там цикл в ксоре будет вообще ничего не изменится.
Для криптографии "типы данных" важны только там, где нужен определенный размер регистра - это или циклический сдвиг, или сложение с переполнением (реализуется через один if).
Нету, но тем не менее 32 бита целой части они вполне обеспечивают. Иначе вся эта порнокриптография тупо не работала бы.
И по 4 бита применяем к 64-разрядному. Ах забыл, без циклов? Тогда анроллинг.
Эндов, оров и сдвигов то тоже нет в драфте жабоскрипта от wvxvw ;) Разбивать делением, клеить умножением? :)
Бля ;) Но массивы же есть?
Вот будем складывать в импровизированную шестнадцатеричную систему.
Короче что и требовалось доказать - полная жопа, когда нет битовых операций...
Есть. Короче тогда хранить переменные в строках в хекс виде. А массивы для операций описывать примерно так:
Хотя вот с аппендом строк сомнительно. Может так
xor_table = {
'0':{ '0':'0', .... 'F':'F'}
...
'F':{ '0':'F',....'F':'0'}
};
Вполне.
Что вы несете-то?
http://crypto-js.googlecode.com/svn/branches/4.x/src/sha1.js
Это не мы несем. Это wvxvw несет вот тут:
http://govnokod.ru/13597#comment191527
И вот тут: "все ту же криптографию можно сделать и обычной математикой".
Ну это я понял. И счел эту фразу призывающей к их удалению ;)
64 наверное все-таки. В 32 битный флоат 32 битное целое не влезет.
От MITM'а хватило бы банального HTTPS. А шифрование на клиенте как бы убирает излишнее доверие к серверу - никто кроме отправителя и получателя не знает, что именно было в сообщениях, даже сервер, через которых их передали.
Но мы то знаем, что сервер может подсунуть кривой жабаскрипт, который сольет сообщение куда надо ;)
исходники же все равно доступны, пусть даже если обфусцированы
Т.е. я каждый раз, перед тем как туда что-то ввести должен перечитывать исходники? :)
Одно дело, когда я собрал на своей машине клиента из исходников. В этом случае я уверен, что в нем ничего не поменяется (если, конечно, мою машину не поимели), и могу спокойно юзать его до следующего обновления.
Совсем другое дело, когда исходник берется с сервера и этот сервер может в любой момент подсунуть мне новую версию...
P.S. Паранойя она такая ;)
Это кстати очень большая проблема (Столлман и об этом предупреждал). Потому ненавижу автообновляющийся софт.
Видится такой радикальный выход - ты апррувишь скрипт, и браузер юзает копию из кеша как 304.
Как только видишь что сайт предлагает обновить - оно лочит и показывает дифф. Хотя и такой подход - не панацея. Всё-равно заебешься читать мегабайты обфусцированного js.
Тут проблема что js может натворить много делов, но он привязан к серверной стороне (там поменяли что-то, надо обновить скрипт), которую мы не можем контролировать.
Проще уж тогда делать шифровалки расширением браузера. Его можно прочитать перед установкой или вообще не обновлять, если не хочется... Хотя с политикой фаерфокса я задолбаюсь править номера версий каждый месяц.
P.S. Может быть есть уже какой-нибудь PGPFox?
Это если сертификаты правильно настроены, не самодельные и ещё какие-то оговорки.
Ну да. Но без HTTPS все это "шифрование в браузере" никакого смысла не имеет. Активным MITM'ом присунут переделанный скрипт да и все. А во всяких халявных вайфаях и интернет-кафе активный MITM устроить совсем несложно.
P.S. Кстати самодельные и самоподписанные тоже можно юзать, с оговорками. Только придется один разок по побочному каналу сверить отпечатки. Например по телефону позвонить владельцу сервера.
0) Шифрование на сервере без HTTPS. Любой пассивный наблюдатель на канале видит сообщения. Админ сервера втихомолку сливает всю переписку PRISM'е.
1) Шифрование на сервере с HTTPS. Пассивные наблюдатели в обломе, админ продолжает читать переписку. Активный MITM может попытаться подсунуть свой сертификат.
2) Веб-шифровалка без HTTPS. Активный MITM или админ сервера (если он рисковый парень, или его кто-то прижал к стенке) могут присунуть свой скрипт. Пассивные наблюдатели в обломе.
3) Веб-шифровалка с HTTPS. Аналогично предыдущему, но активный MITM не может подсунуть скрипт, не подсунув свой сертификат.
4) "Толстый" клиент не имеющий ничего общего с браузером, аля PGP. Подвержен только терморектальному криптоанализу ;)
P.S. Здесь не рассматривается способ получения публичного ключа получателя. Это совсем другая история ;) Машины отправителя и получателя считаются не скомпрометированными.
P.P.S. Все что я хотел этим сказать - то, что юзать вебсервис для передачи конфиденциальной инфы можно только в случае необъяснимого доверия и любви к админу сервиса ;) Чего истинный параноик, которому действительно нужно передавать конфиденциальную инфу, себе никогда не позволит. И то, что веб-криптовалки без HTTPS это всего лишь иллюзия безопасности.
Это именно так, т.к. каждый раз не полезешь проверять, что за js на самом деле выполняется в браузере. Поэтому, идея js crypto, по большому счету - хуйня.
В моей практике был случай по поводу локального говнофорума. На вбуллетине клиентский код делал md5 от пароля, пароль "жертвы" был хитрый, просто так не сбрутфорсить. В итоге было предложено соломоново решение - по идшнику пользователя форум отдавал модифицированную версию скрипта, который не делал ничего.
В тираж не пошло, поскольку нашёлся другой путь. Никто бы и не заметил подмены.
Ну да, в том то и суть, что скрипт может быть изменен очень хитрым образом, который в случае обнаружения можно списать на банальную ошибку/опечатку.
Например, если не хочется палиться, можно немного попортить генератор простых чисел. Скажем, чтобы он вместо 2^256 вариантов выдавал всего 2^32. На глаз это заметить практически невозможно, а ключи, сгенеренные таким алгоритмом подбираются за считанные часы вместо дохреналионов лет ;)
Емнип, всего лишь потому, что тогда java было модным словом, и авторы решили поюзать его в названии своего скрипта ;)
вначале он был LiveScript
Копировали тупо с Си, там где действительно много работы с памятью / эти операции часто бывают нужны. В языках, которые предназначены для прикалачивания кнопок к формам делать специальные короткие имена со специальным синтаксисом для таких операций - просто бред.
Почему никто не вспомнит классику - почему в яве == для обьектов сравнивает ссылки (операция в подавляющем большинстве случаев нахуй не нужная), а равенство обьектов вызывается по .equals()? Почему бы не сделать наоборот, как в питоне?
Синтаксический сахар, транслирующий a == b в a.equals(b)?
Х.з. на самом деле, надо авторов жабы спросить :) Скорее всего не стали делать по той же причине, по которой не перегружаются операторы - предсказуемость их работы. В яве всегда понятно, как работает каждый оператор. и программист на это никак не может повлиять. А тут == бы работало по-разному в зависимости от типов.
Да там вообще всё говёно и перегруженное сравнение не спасет. Я уже где-то писал про длинный пост, про ==,=== и eq. И судя по тому как сделан equals, == мог бы стать NPE-опасным.
Слово throws такое длинное? :) Имхо там список исключений занимает намноооого больше, чем это throws.
Причем даже мне, как крестовику со стажем, extends и implements нравятся больше, чем сишное двоеточие перед предками класса.
> чтобы не писать паблик / приват
Ну оно только в описании членов мешает. А метод он и без того длинный, чтобы public/private занимали пренебрежимо малую его часть.
> как оно используется в Смолтоке
return что-ли?
>return что-ли?
Ну, практически, там это обозначает возвращаемое значение.
Ага. Давайте заменим if на =>, while на |<= и получим очередной аналог J, в котором черт ногу сломит :)
Наэкономится на этом, на самом деле, не так и много. Ну вот сколько у вас в функции return'ов, даже если вы не сектант-одноретурнопоклонник? А implements и extends вообще 1 раз на класс. static'ов в кошерном коде не так много, чтобы задумываться об этом коротком слове.
public, private и т.п. да, еще имело бы смысл. Например паблик +, приват -.
Получится J? А чем плохо? У него вполне логичный и простой синтаксис. Простой в смысле количества синтаксических правил / возможностей интерпретации одной и той же фразы. Я более чем уверен, что если взять непредвзятых подопытных недопрограммистов, и дать одному выучить J, а другому, например, C, то уровень понимания языка приобретенный за одно и то же время у первого будет гораздо выше.
Естественно пабликов. Но сколько процентов кода занимают эти паблики? Мне кажется, что не более 5, если конечно код - не тупой враппер или сгенеренный эклипсом класс с пачкой полей и геттерами-сеттерами для них. Замерять лень.
Но, имхо, словоблудие в яве лечить надо совсем не заменой слов на мусор. А все-таки чем-то более высокоуровневым, и позволяющим писать меньше слов. Чтобы никому даже в голову не приходило экономить нажатия клавиш, меняя их на всякую херню ;)
> например, C
А что в синтаксисе си такого сложного? Ну кроме долбанутого описания указателей на функции, и незнания приоритетов, которое вполне парируется скобками. Все подводные камни си и крестов они дальше, на уровне семантики.
И на момент знакомства у знакомящихся было больше багажа знаний, которые лучше подходили под более сложную грамматику. Так и получилось, что изначально использовать ее было легче.
Ну и тут можно двояко оценить ситуацию: можно подходить с позиций, что а если не пытаться улучшить, или развить, то более эффективным решением будет задействовать имеющиеся знания / предыдущий опыт. Но если развивать, то более сложная грамматика - это плохая база, потому что сложности в ней не обладают большей выразительностью.
Есть много куда более выразительных и одновременно простых языков, но тем не менее в силу привычки изучающим тяжело их освоить не потому что они объективно тяжелые, а потому, что для того, чтобы добиться этой самой выразительности или универсальности авторам нужно было пожертвовать традициями.
Другой вопрос - пригодится ли ему потом это понимание J где-нибудь, если он не математик...
А по мне наоборот вот много где крестосимволы неочевидны, а двоеточие при наследовании как раз няшное.
Но раздражает, сцуко, другое - непоследовательность. Ну если так любите всё делать словами - так сделайте уж, And, Xor и Or. Там 10 символов не жалко, а тут 2 зажали.
Кстати в крестах они есть и словами ;)
Там всё: и нативное, и самописное, работает одинаково тормознуто?
Нативное работает быстро, а нативного достаточно (криптография, распаковка gzip, парсеры xml, json). В lua, если с этим придется столкнуться, проще повеситься, т.к. бинарные операции на динамических языках медленнее на порядки. Вот в wireshakr поддержки питона под виндой какого-то хуя нету, есть только lua, в котором даже oop через жопу.
Имелось ввиду библиотечное.
А если совсем уж нативное, то бишь сишное, то как тогда с портируемостью?
Из коробки, но не в песочнице.
Lua (да и практически любой другой язык) умеет вызывать нативный код. В итоге сравниваем языки, а нативные реализации.
Вот в жабе нативного мало, gzip, парсеры итп - написаны на самом языке. И в итоге они сольют питонским. Это не мешает подключить мне JNI.
Тут противоречие. Если zlib есть под данную платформу, то lua тоже может его использовать (не из коробки).
Если же нет, то и питону оно не светит.
Вот в чем загвоздка.
Тут вопрос даже не распространенности, а принципа. Я не говорю что это плохо, но сишные ноги торчат.
Да и само по себе, там, где у меня в питоне есть os.path или urlparse, в lua будут пользоваться регекспами, которые читаются, как говно.
Сишные ноги торчат у всех динамических языков, т.е. это уже срач статика vs динамика будет :)
Мне лично эти ноги очень мешают. Зная яву, я могу понять почти 100% программ на яве. Зная питон, мне рано или поздно придется или учить сишку, или зависеть от сишников, а в опенсорсе нет ничего хуже, чем зависеть от человека, который тебе ничего не должен.
Плюс ограничения для сишных модулей (нельзя указать, что обьект имплементирует, скажем, list - в питоне это можно сделать только через наследование, интефейсов как таковых нету, ололо, а сишные модули ничего наследовать не могут).
Вот у меня иногда такое ощущение что под этим акком пишут два разных питониста.
Один - адекватный любитель опенсорса, другой - агрессивный вендошколяр твердящий про секту Штульмана.
И да, Штульман - красноглазый ебанат с мозолетоксикозом. Вся вендовраждебная хуйня идет от него, трухвальц сравнительно адекватен. И в этом отношении прыщеблядки сами виноваты, пропагандируя вендекапец. Зарекомендовали себя как ебанаты? Теперь не плачьте.
Может, это два разных опенсорса - один допиленный до юзабельного уровня, второй - ебаный пиздец? :)
Потому
>Я и не говорю что это плохо
ибо тут спорно. Практическая (должно работать быстро) часть видимо взяла гору над религиозной (всё на питоне).
>Вся вендовраждебная хуйня идет от него
Будто это что-то плохое.
Да и всегда оказывается что он был прав, поскольку основывается на логике. Просто в России с тем фактом что винду никто не покупает разница - невелика. А насчет утечек личных данных большинству похер. Сноуден, сноуден - это и так все знали. Посрались и успокоились - никто ж свои акки на фейсбуках с гуглами не стал тереть. И айфоны никто не выбрасывает. А между тем Столлман давно говорил за это.
Торвальдс вот проебал тивоизацию с GPL 2.
Все так ссут кипятком от швабодного, типа оно априори лучше нешвабодного, на самом деле разница есть если a) ты достаточно квалифицирован в этой области, б) если для изменения есть достаточный интерес (скажем, за это денег заплатят, а не просто "надоело, что эта функция делает не то, что мне хотелось бы"). В остальном случае ты обычный пользователь, и не надо себе льстить. Просто так ввязываться в это болото, наслушавшись, пропаганды, что "изменить код может каждый" - это как добровольно пойти в армию на 2 года по той же причине :)
Опыт общения с опенсорсными проектами (и коммитов патчей в них) тоже есть, все люди, которые попадались, крайне адекватны и дружелюбны. Порог вхождения часто велИк, но меня это как-то мало волновало. Challenge же и возможность повысить свой уровень.
Ну а сишку знать нужно любому уважающему себя программисту. Не так уж она и страшна, есть в ней что-то притягательное.
У проприетарщиков аналогичный отказ от ответственности ты подписываешь соглашаясь с эулой ;) Ну хотя да, согласен, они реже портят API и т.п., чтобы не подмочить себе репутацию.
Это только, если питон используется как интерфейс управления каким-то сишным модулем и больше ничего на нем не делают.
>Практическая (должно работать быстро) часть видимо взяла гору над религиозной (всё на питоне).
Лол, ты наверно питон никогда не видел. Работа с двоичными данными на чистом питоне (парсеры, битовые операции), если не найдется сишной функции, сразу просаживает скорость в разы. Так что альтернативы какбэ не было. PyPy не запускал.
То есть это здорово разбавляет радость от питона. Может быть, меня обманули, когда учили питону и не учили C. А может быть, надо заниматься тем, где сишные потроха знать не надо, скажем, веб девелопментом, и не ебать себе мозги?
Ещё Cython попробуй.
Ну это ведь уже не так страшно, как написание кода на самом си? :) Правда питон в цитоне насколько помню сильно уж кастрированный.
Логика "js может за мной следить - давай-ка я от него откажусь" уёбашна. Это как лечить насморк отрубанием головы - чтобы предложить, много ума не надо, и ясно, что никто этим пользоваться не будет.
>Сноуден, сноуден - это и так все знали.
Дай бог, людей будет проще уговорить пользоваться какой-нибудь криптоприблудой. А может, и писечку Серёженьки когда-нибудь из анусов повыдергивают, когда человек получает смартфон, шлющий неизвестно что неизвестно куда.
А насчет Сноудена, проблема просто в том, что вся мощь IT-шного мира сосредоточена в одной стране, ведущей войны, которая таки может заставить секретным соглашением дать возможность в реальном времени видеть все поведение пациента в сети. Сама идея - когда одна страна де-факто контролирует интернет - порочна, какой бы эта страна не была. Может, люди осознают это и начнут выбирать менее удобные / популярные, но более приватные аналоги. Так что Сноуден пришелся вполне кстати. Разбирающиеся люди-то знали и раньше, просто убедить большинство у них возможностей не было, сейчас шансов стало больше.
Стоит различать скрытие инфы от правительств и спецслужб, и скрытие инфы от хакера Васи. Скрывать инфу от Васи полезно каждому человеку, чтобы не оказаться в неприятной ситуации. Скрывать инфу от служб стоит только если ты занимаешься чем-то незаконным, или представляешь для них какую-то угрозу. В противном случае ты им просто нахуй не нужен, как Неуловимый Джо.
Поэтому Сноуден - плохой пример. На его опыте ты большинство не убедишь. А тех, кого можно в чем-то убедить на примере Сноудена убедждать ни в чем не надо, они сами прекрасно понимают ситуацию ;)
Чтобы влиять на большинство нужен человек, похожий на них. И ситуация, более-менее напоминающая их поведение в сети. Например какая-нибудь Маша из Нижнего Тагила, которая выложила во вконтакте свой телефон, и этим воспользовались злоумышленники, сняв деньги с ее банковского счета.
Что это тотальное скрытие инфы даст обычному человеку кроме неудобств? Представьте, что я представитель того самого большинства и объясните мне ;)
Вот если некий малолетний долбоеб узнает мой телефон - он будет мне названивать с угрозами и т.п.. Эта проблема понятна обывателю, поэтому он скорее всего постарается телефон куда попало не светить.
А если спецлужбы видят мой телефон, скрытый в профиле в контакте, то для чего они им воспользуются, если я обычный законопослушный гражданин? А что сделает разведка СШП с моими сообщениями на фейсбуке? :) Да им просто нет смысла их читать.
Поэтому большинству людей на эту ситуацию с "прослушкой" (особенно американской) насрать с высокой башни ;)
А стал бы он, если бы я был тотальным анонимусом, и никогда никуда этой инфой не светил? :) Как раз это навело бы еще больше подозрений.
P.S. Какую инфу я могу выдать сотруднику спецслужб, да такую, что она ему пригодилась в суде? Приведите пример, пожалуйста.
Вернее так. Какую инфу я могу случайно раскрыть на тех же одноклазниках\втентакле, чтобы она оказалась полезной сотрудникам спецслужб, и чтобы у меня был повод оспаривать каналы получения этой инфы в суде, если бы я ее никуда не выкладывал.
"Сегодня я ебал пони".
"Сегодня взорвали магазин, было весело! Фото во вложении".
"Пойдем свергнем Пу?"
Что-то в таком духе? :)
Суд обязан вас защищать, если он разрешил разгласить вашу информацию. Например, по ошибке / не обдуманно нанеся вам вред. Если это сделает кто угодно, без разрешения суда, то никто никто вас защащать легально не будет обязан, только если по доброй воле.
С каких пор хрень написанная на сайтах считается показаниями? Для дачи показаний существуют вполне определенные процедуры, подразумевающие ответственность за ложь.
Если уж они там настолько спелись, то им и этой записи во вконтакте не надо. И без нее найдут повод посадить Васю (или кого-то еще, кто подвернется под руку).
P.S. Ну и вообще, за такие слова в паблике меня этот самый Вася мог засудить за клевету. Поэтому я бы так писать не стал. Т.е. подразумевается, что эта фраза проскочила в приватной беседе с кем-то?
Но проблема то здесь таится совсем не в том, что некий мент сумел прочитать мою переписку о Васе. А в том, что сфабриковали обыск, подсунув нужные предметы. И имхо проще и дешевле найти другой повод для обыска, чем читать переписку всех Васиных друзей.
P.S. Разговор ушел немного в другую тему, но я всего лишь хочу сказать о том, что глупо думать, что народ будет задумываться о конфиденциальности глядя на пример Сноудена. Народу нужно показывать пример того самого Васи. Которого посадили из-за записи о нем в контакте. Такая новость действительно поднимет волну в народе. А Сноуден? А что Сноуден. Он с обывателем имеет мало общего, поговорят немного да забудут.
Педофил Коновалов, подойдет?
Порочная практика, не согласен категорически.
Ну тут же смотря какая инфа. Я же не говорю сливать все подряд без разбора.
Я пытался выразить то, что для большинства людей разглашение инфы Васе-хакеру или Пете-школоло гораздо опаснее, чем всем эти спецслужбам вместе взятые.
Поэтому да, людям надо думать о конфиденциальности. Но в первую очередь не с точки зрения защиты от спецслужб (если они, конечно, не Сноуден с Навальным), а с точки зрения защиты от нехороших людей. Это для них на порядки актуальней.
P.S. Ну естественно, есть вероятность, что какой-нибудь Миша-мент окажется кем-то имеющим доступ к моей инфе, и поюзает ее в своих грязных целях ;)
А зачем это сделано?
Кроме того, это позволяет, например, сделать: array.length = 100500, и не потратить память при этом.
Но это делает их тормозными / традиционный подход для работы с массивмаи часто оказывается непригодным.
Вобщем, недальновидная попытка упростить жизнь, которая в последствии отрезала путь к развитию.
Не надо из массивов на гигабайт удолять элементы. Не надо вообще выделять огромный непрерывный кусок памяти.
Надо развиваться в другую сторону - использовать структуры c меньшей алгоритмической сложностью, те же rope.
Практически во всех ЯВУ языках массивы оборачивают более высокими абстракциями.
Ничего про их балансировку (Чтоб от log n не уходили к n) никогда не слышал.
А потом, емнип, на этой хуйне не работают foreach и map :)
Но в жс всегда все кверху жопой ;( И foreach неюзабелен чуть менее чем полностью. А ради обхода городят всякие костыли типа _.each() в underscore.
В жабаскрипте - увы, foreach изначально ущербен. Он возвращает только ключи, а значения потом приходится выдирать из "массива" самому. В итоге алгоритмы обходящие "массив" хоть и остаются в теории O(n) (если верить, что там хорошая хешмапа, и считать что у нее O(1) на выборке), но константа-то растет... тормозят то они больше...
А трабла с обходом массива, емнип, заключается в том, что форич оббежит не только элементы массива, но и унаследованную херню из прототипа. Куда очень любят добавлять свои методы всякие либы.
И вот так куда не копни в жс - везде костыли и сомнительные ходы проектировщика. Хуже крестов, честное слово ;(
'a' in {'a':1,'b':2,'c':3}
проверяет вхождение элемента в структуру
>>Хуже крестов, честное слово ;(
Ну уж нет. Он минималистичен. Там правил во всем языке меньше чем контрисключений из исключений из правил в крестах.
проверяет вхождение элемента в структуру
Эт че?
А что там сделано? Создаются элементы за пределом, если вышло?
Да на ГК много чего не хватает. Как-то обходимся.
Ну вопрос был больше про "что делает || ?" Я привык видеть на выхлопе этих операторов true/false (ну или 1/0, соответствующие константам TRUE/FALSE).
Насколько понял из вашей реакции, || - не совсем logic or. Он возвращает либо false, либо то, что посчитал не-false? Так понятнее.
...Собственно, чего я спрашиваю, консоль же под рукой. :) Поэкспериментировал - || и && возвращают то значение, которое последним "посмотрели". Удобно, наверное... Но как-то руки не поворачиваются такое писать. :) Может просто с непривычки, какая-то логика в этом есть...