Комментарии 72
Вообще-то современные браузеры игнорируют эту ошибку)
Это не значит, что ошибка перешла в разряд фич)
Ну так это же конференция. На них обычно рассказывают о будущем.
А ECMAScript 5 допускает так ставить запятые.
Так что для конференции баннер нормальный. %)
А ECMAScript 5 допускает так ставить запятые.
Так что для конференции баннер нормальный. %)
На самом деле удобно, когда код JS формируется динамически другим приложением, не обрезать последнюю запятую
Удобно использовать join, а не поэлементный вывод.
с большими объемами данных не всегда рационально, проще приклеить следующий блок данных к текущему, чем вызывать join
Не поверите, но с большими данными джоин массивов обычно справляются лучше канкатенации строк. Да и код выглядит приятней.
не поверите, но кроме больших объемов данных, бывают данные очень больших объемов или данные с неизвестным заранее объемом, потоки данных.
Работа со строками более накладна чем с массивами. Бывают моменты когда работа со строками быстрей, но этих моментов меньше, поэтому можно их смело отложить в сторону до времен «когда будет тормозить». Работа с массивами более эстетична, и визуално более понятна.
По мне так работа с массивами выглядит аккуратней. И даже если бы она была медленней, я бы ее всеравно использовал бы чаще.
for( key in items )
{
buffer.push( items[key] );
}
return buffer.join( ' , ' ); // prepare where in conditions
for( key in items )
{
in += ',' + items[key];
}
return in.slice(1); // prepare where conditions, not need first comaПо мне так работа с массивами выглядит аккуратней. И даже если бы она была медленней, я бы ее всеравно использовал бы чаще.
Хорошо. У вас есть функция, которая добавляет за раз к строке одну порцию данных. Через запятую. Вы будете организовывать через массив?
У меня нет функции которая добавляет за раз одну порцию данных, у меня есть функция которая собирает данные в удобной форме, и затем лепит их в одну строку из удобных данных. И как я говорил выше, чаше «удобная форма данных» — именно массив, им проще манипулировать чем одной сплошной строкой.
Худший из вариантов, но в любом случае лучше чем просто конкатенация:
Вариант хоть и на регулярке, но он лучше. А лучше он удобством, простотой и универсальностью. Конкатенация — неудобный вариант. Плюсики строк — убоги, и подходят лишь для лепки пары кусочков строки (имя фамилия и подобных).
Худший из вариантов, но в любом случае лучше чем просто конкатенация:
var str = "hello #{username}! You got an message '#{message_subject}' on #{message_date}."
q.replace( /#{(\w+)}/, function(text, match){
return data[match] || '';
} )
Вариант хоть и на регулярке, но он лучше. А лучше он удобством, простотой и универсальностью. Конкатенация — неудобный вариант. Плюсики строк — убоги, и подходят лишь для лепки пары кусочков строки (имя фамилия и подобных).
Опечатка
q.replace = str.replace
q.replace = str.replace
т.е вы приводите пример, с которым я-то и не спорю (join массива), а другие видеть не хотите, потому что у вас таких задач нет? А у меня недавно была задача. Нужно было на ajax запрос дать ответ: куча координат, разделенных запятой. В серверной части я посчитал нерациональным сначала получить массив координат, а потом джойнить их через запятую т.к. массив тут явно лишнее звено. Я просто сделал $result .= "$x,$y,"; и после цикла chop $result (убрал последнюю запятую). Получилось очень просто и удобочитаемо. Сереьрянной пули, как вы понимате, не существует в программировании. Имеют права на существование разные подходы
А могли бы отдать массив =) Или аяксом гонять массив в наши времена некошерно? А еще я не понимаю какой смысл в строке:
2,3,54,324,5567,504,938,49578,3827,2384,48374,38484. Вы ее так в чистом виде и показывали клиенту? Или всетаки разбивали и делали с ними что-то? Если второе то какой смысл в строке, если можно передать массив? Если первое, то можно было просто сделать echo $x, ',', $y, ','; (Да, именно запятые, это не опечатка) и результат был бы таким же самым.
2,3,54,324,5567,504,938,49578,3827,2384,48374,38484. Вы ее так в чистом виде и показывали клиенту? Или всетаки разбивали и делали с ними что-то? Если второе то какой смысл в строке, если можно передать массив? Если первое, то можно было просто сделать echo $x, ',', $y, ','; (Да, именно запятые, это не опечатка) и результат был бы таким же самым.
по http ходят-то не массивы и объекты, а строки. В любом случае, на клиентской стороне будет какой-то парсер. Например, json. Либо же, если не требуется сложной логики: приходит строка с числами через запятую — она же, вуаля, и интерпретируется как массив. Посмотрите внимательно мое первое сообщение: я говорю о методе формировании этой строки на серверной стороне.
К чему я веду:
1. Конкатенация — зло, чтоб изменить что-то не в конце/начале строки, требуется потрудиться
2. Работа с массивами в разы удобней чем со строками, и быстрей.
3. Для того же аякса уже создано много средств (в Вашем случае json_encode — JSON.parse) они быстрей и сделаны специально для того чтоб передавать/получать данные в удобной форме.
Даже если ограничиться этими тремя пунктами (а вообще по хттп ходят не строки а биты), то конкатенацию можно уже убрать на второй план, как убогий и неудобный способ составления данных.
Я согласен только в одном: конкатенацию удобно использовать когда лепишь данные типа имя и фамилия, город и страна и подобные.
1. Конкатенация — зло, чтоб изменить что-то не в конце/начале строки, требуется потрудиться
2. Работа с массивами в разы удобней чем со строками, и быстрей.
3. Для того же аякса уже создано много средств (в Вашем случае json_encode — JSON.parse) они быстрей и сделаны специально для того чтоб передавать/получать данные в удобной форме.
Даже если ограничиться этими тремя пунктами (а вообще по хттп ходят не строки а биты), то конкатенацию можно уже убрать на второй план, как убогий и неудобный способ составления данных.
Я согласен только в одном: конкатенацию удобно использовать когда лепишь данные типа имя и фамилия, город и страна и подобные.
омг, тег забыл закрыть, вот блин :) Это случайность.
не может быть работы с массивом быстрее работы со строкой в принципе: скриптовые языки выделяют память под строку с запасом, в процессе может увеличиваться тоже с запасом, каждая итерация конкатенации к текущей строке делается гораздо быстрее чем обращение к элементу массива, поскольку не надо выделять память, просто копи несколько байт и все.
Увеличить размер строки в памяти невозможно, при изменении строки, комп берет длину текущей строки + длину добавляемой строки и резервирует новое место в памяти такого размера, затем копирует туда новую слепленую строку и удаляет старую. Предвидеть длину он не может заранее. Работа же с массивами по другому немного работает, поэтому если Вы будете лепить строки постоянно, это сильно замедляет работу. Для этого в языках типа c# или java придуманы всевозможные string builder-ы, которые по сути массивы строк, и именно ими рекомендуют пользоваться при конкатенациях.
Если в массив добавлять в конец значения, это очень быстро, как и извлечение с конца. В таком случае он работает как стек, а это очень быстрые операции. + вместо циклического изменения строки в памяти он это делает один раз в конце при join-е. Поэтому именно для конкатенации массив подходит не плохо.
Если в массив добавлять в конец значения, это очень быстро, как и извлечение с конца. В таком случае он работает как стек, а это очень быстрые операции. + вместо циклического изменения строки в памяти он это делает один раз в конце при join-е. Поэтому именно для конкатенации массив подходит не плохо.
В шарпе будет медленнее та как строки неизменяемые. А вот, скажем, в перле будет быстрее конкатенация, я даже проверил это (больше чем в 2 раза быстрее, хотя зависит от конкретики), поскольку там именно такой алгоритм выделения памяти, средства языка позволяют это проверить даже, и я проверял. Если в какой-то реализации и/или языке конкатенация будет быстрее — это ли не доказательство, что ее иногда целесообразней использовать?
Join (var a = ['qw','er','ty']; var res = a.join(',');)
— 498
========
Concat (var a = ['qw','er','ty']; var res = a[0]+','+a[1]+','+a[2];)
— 904
========
Result
— Difference concat vs join: -81.52610441767068%
Протестировано на 10 миллионах итераций
— 498
========
Concat (var a = ['qw','er','ty']; var res = a[0]+','+a[1]+','+a[2];)
— 904
========
Result
— Difference concat vs join: -81.52610441767068%
Протестировано на 10 миллионах итераций
так, именно, метод «без join» позволяет не использовать массив, а обращение к элементу массива — слабое звено. Так что пример не в тему. Я совсем не против join (было бы глупо спорить против такого полезного оператора), но очевидно, что есть ситуации, когда эффективней будет конкатенация. Если пойдет жесткий спор, придется и мне приводить примеры и тесты
А еще удобнее — специализированные библиотеки. ;)
for (var i = 0; i < 10; i++) {
i && process.stdout.write(','); // Магия ;)
process.stdout.write(i);
}
IE7 точно валиться, а его большинство сапортят пока…
Его и будут дальше поддерживать вне зависимости от того, любите ли вы его лично или нет.
Поддерживать его дальше, чтобы люди пользовались им дальше и нам опять придется поддерживать IE7.
С какого такого бодуна? Этот выкидыш практически нигде и никем не используется, да и мало чем отличается от шестого. Так что если поддерживать и будут — то «по остаточному принципу» и не весь функционал.
Мы не поддерживаем. На достаточно посещаемых проектах. Его доля – крайне низка. Даже ниже IE6.
Браузеры могут и игнорировать, но человек не может.
Мне кажется в английском тоже ошибка: не «theme», а «subject», «theme» — это «тема» совершенно в другом смысле.
И с табуляцией полный бардак.
Не считаю это ошибкой. Тут «theme» вполне употребимо в смысле «основная идея конференции».
Вообще человек прав :)
theme
1. A topic of discourse or discussion. See Synonyms at subject.
www.thefreedictionary.com/theme
theme
1. A topic of discourse or discussion. See Synonyms at subject.
www.thefreedictionary.com/theme
Или вот: lingvopro.abbyyonline.com/en/Translate/en-ru/theme
1) тема, предмет, вопрос (обсуждения, лекции и т. п.)
pro100tak заслужил инвайт на конференцию!
До конференции остался 51 день
А у меня аккурат через 2 месяца дочь родится (прогноз — 4 июня +- 2 недели). Куда уж мне :)
А у меня аккурат через 2 месяца дочь родится (прогноз — 4 июня +- 2 недели). Куда уж мне :)
Извините, это ответ на этот комментарий
у меня сын должен был родиться 5-го мая, я родился позавчера :) Скучно ему, видимо, стало
Я вам хочу сказать это сто процентов такой маркетинговый ход, потому что я определенно долго не мог увести глаз с аналогичной, но другой картинки с не закрытой фигурной скобкой.
Видимо писали питонщики…
Это не ошибка :)
w3c не имеет отношения к стандарту языка ECMAScript.
Да, афаик, IE глючит на этом коде, но это полностью соответствует спеке:
Обратите внимание на первую строку, последнюю продукцию, там есть запятая после декларации всех свойств.
w3c не имеет отношения к стандарту языка ECMAScript.
Да, афаик, IE глючит на этом коде, но это полностью соответствует спеке:
ObjectLiteral = { } | { PropertyNameAndValueList } | { PropertyNameAndValueList , }
PropertyNameAndValueList = PropertyAssignment | PropertyNameAndValueList , PropertyAssignment
...
Обратите внимание на первую строку, последнюю продукцию, там есть запятая после декларации всех свойств.
искал я как-то на чужом сайте такую ошибку. дня 3 искал…
Вчера не мог зарегистрироваться на событие из за ошибок в js на форме.
А ещё, на этом баннере в качестве фона выступает, как бы, листик в линию. Но строки кода находятся не на линиях.
fixed;
у меня баннер не открывается в IE, что там написано?
Не стоит забывать о том, что изготовление и размещение баннера — это священнодейство маркетологов. А им глубоко фиолетово как именно оно сделано, главное, чтобы:
1. Креативно.
2. В срок
3. С минимальным бюджетом.
Все эти критерии, на взгляд рекламщика были соблюдены.
На моей памяти только один менеджер от заказчика при приемке всегда проверял результат на нескольких браузерах.
P.S. А может быть это был продуманный ход, для привлечения большего внимания?
1. Креативно.
2. В срок
3. С минимальным бюджетом.
Все эти критерии, на взгляд рекламщика были соблюдены.
На моей памяти только один менеджер от заказчика при приемке всегда проверял результат на нескольких браузерах.
P.S. А может быть это был продуманный ход, для привлечения большего внимания?
Если убрать var то это же стиль Python!
К слову, заметил на руби-тостере, что сайт тостера сжирает 50-100% цпу на маке в хроме даже в неактивной вкладке. Не знаю с чем связано, наверняка лишний код по таймеру или в цикле. Есть еще страдающие этим?
Это не ошибка, ошибку выдаст только IE, потому что не поддерживает спецификацию
Моё маленькое ИМХО :) Не люблю когда строки пишут в одинарных ковычках :)
Не знаю почему, но мне это режет глаз. Это наверное у меня пошло от С, С++, где одинарные это один символ, а двойные строки. Поэтому всегда придерживаюсь писать строки в двойных ковычках, даже когда щас больше пишу на PHP, Ruby, Python, JS :)
Не знаю почему, но мне это режет глаз. Это наверное у меня пошло от С, С++, где одинарные это один символ, а двойные строки. Поэтому всегда придерживаюсь писать строки в двойных ковычках, даже когда щас больше пишу на PHP, Ruby, Python, JS :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Баннер конференции о JS с ошибкой в JS